povray.unofficial.patches message digest

[Mr] Re: POV-Ray 3.8 beta 2 for Windows build with Mi... [252 days 5 hours and 43 minutes ago]

Mon, 4 Aug 2025 10:25:00 GMT

"Mirosław" <nomail@nomail> wrote:
> I've made patch to build POV-Ray 3.8 beta 2 for Windows using MinGW.
> File syspovconfig_mingw32.h was created and few changes made to syspovconfig.h,
> pvedit.cpp, pvengine.cpp and ImfSystemSpecific.h files.
>
> The most important was get rid of dependence on __try/__except which isn't
> supported in MinGW.
>
> Tested with MSYS2 MinGW (https://www.msys2.org/).
> Build for Windows XP is possible with TDM-GCC
> (https://jmeubank.github.io/tdm-gcc/).
>
> Code:Blocks workspace/project files are attached.

It's always good to have more build workflows polishing POV-Ray's
compatibility/ubiquity, thank you so much !

[Mirosław] POV-Ray 3.8 beta 2 for Windows build with MinGW [256 days 20 hours and 28 minutes ago]

Wed, 30 Jul 2025 19:40:00 GMT

I've made patch to build POV-Ray 3.8 beta 2 for Windows using MinGW.
File syspovconfig_mingw32.h was created and few changes made to syspovconfig.h,
pvedit.cpp, pvengine.cpp and ImfSystemSpecific.h files.

The most important was get rid of dependence on __try/__except which isn't
supported in MinGW.

Tested with MSYS2 MinGW (https://www.msys2.org/).
Build for Windows XP is possible with TDM-GCC
(https://jmeubank.github.io/tdm-gcc/).

Code:Blocks workspace/project files are attached.

[Mr] Re: yuqk feature requests / suggestions [385 days 1 hour and 43 minutes ago]

Mon, 24 Mar 2025 14:25:00 GMT

"ingo" <nomail@nomail> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "ingo" <nomail@nomail> wrote:
> >
> > I'm just thinkin' out loud.
>
> I hear you, loud and clear.
>
> Ok, this gets wild. The Nim programming language
> https://nim-lang.org/docs/manual.html has 'real' macros. They can be used to
> create a complete language. That language can be POV-Ray like. Using that you
> can output POV-Ray SDL, loops unrolled and all.
>
> The language is compiled, but it also has a interpreted script part, that is the
> same language. The compiled part and the script part can be "linked". That way a
> complete front end for POV-Ray could be build and you'd have a type system,
> objects =structs, minimal OOP (only composition) and it looks a bit like python
> but way faster. Sadly I'm way to incompetent to get something like that
> together.
>
> This is the mesh macros in nim:
> https://gist.github.com/ingoogni/ca030e955daf7f8138cedfe488ca0013
>
> Why I think of things like this? Because the effort of writing all those arrays
> and remembering what they do and how they interact often gets too much (age).
>
> ingo

Sorry to cross over if it's off topic, but about Nim, I asked a question on
this, or maybe something else depending on what you meant... in the other thread
I had started about curly braces / indentation scoped languages. thanks for
sharing your discoveries.

[ingo] Re: yuqk feature requests / suggestions [804 days 22 hours and 38 minutes ago]

Mon, 29 Jan 2024 17:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "ingo" <nomail@nomail> wrote:
>
> I'm just thinkin' out loud.

I hear you, loud and clear.

Ok, this gets wild. The Nim programming language
https://nim-lang.org/docs/manual.html has 'real' macros. They can be used to
create a complete language. That language can be POV-Ray like. Using that you
can output POV-Ray SDL, loops unrolled and all.

The language is compiled, but it also has a interpreted script part, that is the
same language. The compiled part and the script part can be "linked". That way a
complete front end for POV-Ray could be build and you'd have a type system,
objects =structs, minimal OOP (only composition) and it looks a bit like python
but way faster. Sadly I'm way to incompetent to get something like that
together.

This is the mesh macros in nim:
https://gist.github.com/ingoogni/ca030e955daf7f8138cedfe488ca0013

Why I think of things like this? Because the effort of writing all those arrays
and remembering what they do and how they interact often gets too much (age).

ingo

[Bald Eagle] Re: yuqk feature requests / suggestions [804 days 23 hours and 33 minutes ago]

Mon, 29 Jan 2024 16:35:00 GMT

"ingo" <nomail@nomail> wrote:

> If we had a struct specific for spheres, we'd still need to initialize it and
> declare a sphere with it to later be able to identify that one specific sphere.

Well ... yeah.  But there are nuances to that, I guess.

We initialize blob spheres with a strength, so clearly we have an extant data
structure for spheres and cylinders that we can use/abuse to hold "metadata".
There's also the matter of automating such entry into arrays vs manual entry.
For automation, we need "handles" to grab things by and place them into the
array.
If primitives were assigned ID's when they were parsed (let's ignore any CSG
hierarchy for now), then there would be at least that.  I can run a #for loop on
everything if there were a last_assigned_id keyword or a way to check for an
undefined id.  And that way nearly everything would have a unique id (again,
ignoring CSG)
Also, returning to the idea of having a point {} primitive or a whole
point_cloud {}, it would make it vastly easier to put a specific coordinate
location into an array if the ability to do something like
center {sphere <x, y, z> Radius translate, rotate, scale, etc...}
were possible.  As it stands, I'd have to go through a whole rigamarole to
figure out exactly where that sphere center ended up, before I placed the value
into the array.
Then a year and a half later, when I wanted to do the same thing, I'd have to
excavate that code, remember how it worked, if the HDD it was on wasn't dead,
..... etc.

> When I need something like that I use an external program to generate a large
> array with struct like data and generate the spheres from that with a macro
> loop. The index of the sphere is then the identifier. All sphere parameters are
> accessible and modifiable through the array. Multiple sphere types, like your
> isotopes, are then multiple type specific arrays. You could also put your
> metadata in an/the array.
>
> If we had structs, we'd put structs in the array(s) just the same way.

Yes, of course, there's (almost) always "a way".
And this was exactly the answer I was expecting to be brought up by - someone.

The point is, that it helps people, especially new users, accomplish a task,
quickly and relatively easily, without tearing their hair out and screaming "F
POV-Ray, who uses this stupid program?"
What you propose is certainly an option, but I have a disdain for detachable
include files that can get lost or undergo versioning chaos, and as we all know,
SDL is SLOOOOOOW.

So yes - putting everything into arrays is the way to go.  But the question is:
how do we initially _get_ everything into the array?

It's fine if you have coding experience, and have the forethought and
organizational skills, and discipline to make it all happen, AND you're starting
from scratch.  But if all I want to do is use a sphere in a union as an
attachment point or center of rotation, then every time I transform that sphere,
I have all sorts of things to keep track of and calculate.  If I can just "grab"
that Nth sphere out of the union and instantly have that <x, y, z> coordinate in
hand, then it makes SO many tasks 1000 times easier.

What happens if Pavel Rae posts a nice scene that's all spheres and cylinders,
but I want to use the same assembly as a mesh?  Forget about the actual
conversion to that data structure - I don't even have access to the point data
yet.

And that's what people want.  We don't have a modeler, we don't have a GUI - so
we need _something_ to make the end-user experience ... better - or else we're
not competing in the marketplace of ideas and features, and computer graphics
power.

I hate gift cards, because the representative value is locked into one purpose.
$20 on a Wendy's card doesn't allow me to buy $20 of gas if I need it more than
a fast food lunch.  Currency is easily exchangeable for anything.  And what I'm
suggesting is looking at the data that's in a scene file as currency, not
informational value that's locked into a digital gift card because "that's what
the user intended it for".

You know I'm not just idly complaining, or lazy, or unmotivated - but sometimes
I would love to just be able to accomplish a task in an afternoon or a weekend,
rather than over a 5 year period, because the informational tools that I need
are within reach.  I'm sure I've delved into topics that people with actual
degrees in computer science haven't covered, or at least not to the depth I've
explored them.  And while I've learned a lot, and am better for it, sometimes it
would just be nice to let an idea flow, and come to fruition without having to
start another PhD-level investigation into matrices, calculus, tensors,
statistics, floating point math....

All this is just to brainstorm ideas and potential approaches.
We could even have a separate parser for all I care, that can handle the
analytical and algorithmic tasks separately, and be run separately, so as to not
further complicate the central code base.

But having certain tools available changes everything.
Try to copy something without ready access to a photocopier, scanner, or cell
phone camera.
Boom - you're back in the 1970's.

And I understand.   We don't have a developer.  We have 30 years of macros and
include files to sift through, and vast libraries of unexplored routines that
haven't even been converted to SDL, let alone implemented in source.

I'm just thinkin' out loud.

[ingo] Re: yuqk feature requests / suggestions [805 days and 28 minutes ago]

Mon, 29 Jan 2024 15:40:00 GMT

"ingo" <nomail@nomail> wrote:

> If we had structs, we'd put structs in the array(s) just the same way.
>

missed a bit,

but in general, I would welcome access to any data inside of POV-Ray.

Also, it would be nice is something like this worked:


//sphere-struct
#macro Sphere(name, _centre, _radius)
  #declare name&_centre = _centre;
  #declare name&_radius = _radius;
  sphere{name_centre, name_radius}
#end

object{
  Sphere("first", <0,0,0>, 1)
  texture {pigment{rgb 1} finish {ambient 1}}
}

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

#debug concat(str(first_radius,0,0), "\n")

[ingo] Re: yuqk feature requests / suggestions [805 days and 48 minutes ago]

Mon, 29 Jan 2024 15:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Just unloading some more thoughts for the record.


If we had a struct specific for spheres, we'd still need to initialize it and
declare a sphere with it to later be able to identify that one specific sphere.

When I need something like that I use an external program to generate a large
array with struct like data and generate the spheres from that with a macro
loop. The index of the sphere is then the identifier. All sphere parameters are
accessible and modifiable through the array. Multiple sphere types, like your
isotopes, are then multiple type specific arrays. You could also put your
metadata in an/the array.

If we had structs, we'd put structs in the array(s) just the same way.

ingo

[Bald Eagle] Re: yuqk feature requests / suggestions [805 days 1 hour and 28 minutes ago]

Mon, 29 Jan 2024 14:40:00 GMT

Just unloading some more thoughts for the record.

Prism has always annoyed me, because it only takes 2D vectors, and I wind up
having to do a lot of unnecessary conversions when I'm starting with 3D points,
and wanting to do something with prisms.

Apparently polygon {} already has the inbuilt feature that prism {} _should_
have.

"All points of a polygon are three-dimensional vectors that have to lay on the
same plane. If this is not the case an error occurs. It is common to use
two-dimensional vectors to describe the polygon. POV-Ray assumes that the z
value is zero in this case."
https://wiki.povray.org/content/Reference:Polygon


Exploring Thomas Fester's modeling-with-blobs method, it occurred to me that
blobs should have an _optional_ strength argument, and perhaps a new keyword
such as blob_strength can be included in a blob definition to set a default
strength.

The purpose of that would be to simply allow enclosing some vast collection of
spheres and cylinders in an extant scene to be wrapped by a blob {} statement
and still function - without having to edit every single damned line to include
a strength component.

Part of what I see in other software packages is the sophisticated handling of
data structures such that the user doesn't have to sit there and puzzle out how
to hand-reformat all of their data to fit into some other feature's input.

If I take the sine of a vector, I ought to get a vector with all the components
being the sines of the original vector components.
Same with taking the sine of a matrix.

POV-Ray currently has no "point" primitive, even though that's probably the
fundamental thing we all use that underlies all of the other primitives.
The "where" of everything.

We have center points for spheres, tori, endpoints for cylinders, corner points
for boxes, etc.

But when that data is embedded into a primitive {} statement, it's no longer
accessible to the SDL in any [convenient] way.

Something interesting would be to have an "extraction" feature whereby one could
enclose an object - lets say a simple union of cylinders and spheres - in curly
braces or parentheses, and the keyword operating on that would extract an array
of points and their associated primitive types.

The key idea here is the ability to elaborate on existing work, rather than
having to laboriously and time-consumingly deconstruct, dissect, analyze,
scheme, plan, and reconstruct an otherwise perfectly good data set so that you
can get on with the derivative work that you had in mind in the first place.

Another related idea is the fact that users frequently have a need to keep track
of objects and their positions, and need ways to maneuver them into specific
positions.


If I have two instances of an object, but they are hand-modeled or the result of
measurements or automated scripts - where the second is perhaps rotated and
translated into another specific position relative to the first (but obviously
not a COPY of the first placed with rotate or translate) then it would be useful
to have some 3D fitting algorithm that maps Item1 to Item2 and returns a
transform matrix. (obvious this is complicated and fraught with limitations)

A stumbling block that can be encountered is that all spheres are the same.  In
terms of the fact that they are all just sphere {} objects.  One can not track
any individual sphere.  This used to be an extremely limiting problem in
chemistry - because all atoms of the same type were the same.
Until we discovered isotopes.  They still react the same, but they have
different nuclear properties that we can look at and see that they are
different.
Being able to "tag" specific primitives with "metadata" that they carry with
them would be a useful feature, especially if that data could be queried.

This goes back to using the VISIO paradigm of SmartShapes and SmartSheets, but
one could readily see that if the only metadata associated with an object was
its normal vector, then that could potentially save an enormous amount of
calculation, since the metadata normal vector would be transformed along with
the object it is already attached to.

- BW

[William F Pokorny] Re: yuqk feature requests / suggestions [822 days 14 hours and 26 minutes ago]

Fri, 12 Jan 2024 01:41:35 GMT

On 1/11/24 19:02, Bald Eagle wrote:
> So, I'd be able to just plop a decimal argument in, and use binary functions on
> it?
> Simple code example?

#version unofficial 3.8; // yuqk
#if (file_exists("version.inc"))
     #include "version.inc"
#end
#if (!defined(Fork_yuqk))
     #error "This POV-Ray SDL code requires the yuqk fork."
#end

#include "functions.inc"
#declare FnXor = function (a,b) {
//  f_64x_ui1_toflt(  // For explicit conversion back to float
     f_64x_ui1_xor(
         f_64x_ui1_fltto(a),
         f_64x_ui1_fltto(b),
         4  // Internal conversion xor result back to a float
     )
//  )
}

#debug concat("xor(7,3) ",str(FnXor(7,3),3,0),"\n")

#error "Stopping after parse"

Note. Due the differences in double and unsigned long integers, values 
are limited to a zero to pow(2,53)-1 range where doubles are involved.

Bill P.

[Bald Eagle] Re: yuqk feature requests / suggestions [822 days 16 hours and 3 minutes ago]

Fri, 12 Jan 2024 00:05:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/11/24 16:06, Bald Eagle wrote:

> A reason I added a collection of 64 bit inbuilt functions to the yuqk
> fork. The current set:
>
> f_dec64x_ui1
> f_enc64x_ui1
> f_64x_ui1_and
> f_64x_ui1_or
> f_64x_ui1_xor
> f_64x_ui1_not
> f_64x_ui1_shr
> f_64x_ui1_shl
> f_64x_ui1_toflt
> f_64x_ui1_fltto
> f_64x_ui1_popcnt
> f_64x_ui1_ror
> f_64x_ui1_rol

Very nice.  :)

> ... I think these can be handled reasonably well with macros.

:|

So, I'd be able to just plop a decimal argument in, and use binary functions on
it?
Simple code example?

Thanks.

- BW

[William F Pokorny] Re: yuqk feature requests / suggestions [822 days 17 hours and 32 minutes ago]

Thu, 11 Jan 2024 22:35:49 GMT

On 1/11/24 16:06, Bald Eagle wrote:
> Is bitwise_xor () a valid numeric expression for POV-Ray functions?   Nope.

A reason I added a collection of 64 bit inbuilt functions to the yuqk 
fork. The current set:

f_dec64x_ui1
f_enc64x_ui1
f_64x_ui1_and
f_64x_ui1_or
f_64x_ui1_xor
f_64x_ui1_not
f_64x_ui1_shr
f_64x_ui1_shl
f_64x_ui1_toflt
f_64x_ui1_fltto
f_64x_ui1_popcnt
f_64x_ui1_ror
f_64x_ui1_rol

Specifications in hex, binary - maybe, but at the moment I think these 
can be handled reasonably well with macros.

Bill P.

[Bald Eagle] Re: yuqk feature requests / suggestions [822 days 18 hours and 58 minutes ago]

Thu, 11 Jan 2024 21:10:00 GMT

xor (x, y)

"Hey, this looks like a cool pattern to _quickly_ implement..."

Famous last words.

Is bitwise_xor () a valid numeric expression for POV-Ray functions?   Nope.

So I had to make a function to grab the kth bit of the binary representation of
decimal integer N.
Then an xor function.
Then a function that reassembles the xor'd bits into a decimal value.
Then puzzle out how to properly visualize that in a pigment {function {}}
statement, given all the things peculiar to POV-Ray.

All in all quite a bit longer than I expected it to take.

Perhaps consider adding (probably under-the-hood) dec2bin conversion functions.

Also binary functions, taking decimal arguments.
You may just want to have generic binary functions that take 2 arguments - the
number as an argument, plus the base the argument is in (maybe hex).
Or maybe there's a whole other system of doing all that, which makes more sense.

 - BW

[William F Pokorny] Re: yuqk feature requests / suggestions [829 days 7 hours and 30 minutes ago]

Fri, 5 Jan 2024 08:37:37 GMT

On 1/4/24 13:29, Bald Eagle wrote:
> If I don't get to it at some point in the near future, I'd suggest an include
> file that allows users to employ these in a somewhat more "code readable"
> fashion.  By that I mean that f_r should have an alias function declared such as
> 
> #declare vector_length = function {f_r (x, y, z)}

Thanks for the input!

---

The yuqk fork already has inbuilt f_length() and f_length_sqr() 
functions. The former added in part as a clearer alternative to f_r(), 
but it and f_length_sqr() also wrap POV-Ray's internal vector template 
functions called length() and length_sqr(), respectively. The f_r() 
implementation is hard coded c++ math.

The f_r() and f_length() results should be identical for sane inputs, 
but pulling that internal code out to something SDL/VM accessible gives 
us a way to sanity test the both the internal template functionality and 
that equivalence as part of the include's self testing code.

Aside: The yuqk fork has too an f_hypot() function for two inputs (2D 
vectors). Initially it wrapped C++'s std:hypot() as being safer with 
respect to internal overflows, but I found the std::hypot performance 
slow. Today it's just sqrt(x*x + y*y) as the main reason to have the two 
input form over just f_length() with one input at zero, is performance.

As for sgn(), the yuqk fork has the inbuilt functions: f_sign(), 
f_sign0(), f_signpow() and f_signsqrt().

Bill P.

[Bald Eagle] Re: yuqk feature requests / suggestions [829 days 21 hours and 38 minutes ago]

Thu, 4 Jan 2024 18:30:00 GMT

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

> Anyhow. In general, I agree with the suggestions in your post! :-)

I had a bit of time to wind down after work, and got sucked back into playing
with pigment function {}} patterns.

There are certain functions that we already have and that can be used in clever
ways (Thanks TOK) such as f_r and select ();

If I don't get to it at some point in the near future, I'd suggest an include
file that allows users to employ these in a somewhat more "code readable"
fashion.  By that I mean that f_r should have an alias function declared such as

#declare vector_length = function {f_r (x, y, z)}

and TOK's various select () permutations might be confusing to employ without a
little cheat sheet.

I'm considering writing some "help functions" that store the valid domains of
various functions, such that it's easy to output to the debug stream, use as a
protective wrapper / sanity check for avoiding parse errors, graphing the valid
domains of the functions, and probably an insert-menu cheat sheet would be a
simple but useful idea as well.

Anyway, that was a long-winded lead-in to the fact that I often find myself
needing to use some of the odder trigonometric functions and their inverses, and
the following ought to be in-built functions.

#declare fmod = function (Value, Modulo) {select (Value, 1 - mod (abs (Value),
Modulo), mod (abs (Value), Modulo))}  // this gives a mod function that remains
consistant across the origin

// trigonometric functions
#declare csc = function (N) {1/sin(N)}
#declare sec = function (N) {1/cos(N)}
#declare cot = function (N) {1/tan(N)}

// inverse trigonometric functions
#declare acsc = function (N) {asin(1 / N)}
#declare asec = function (N) {acos(1 / N)}
#declare acot = function (N) {atan(1 / N)}

This reminds me to look into hyperbolic and spherical functions as well...

With regard to interesting functions that (barring TOK-level functional coding)
likely can "only" be coded as algorithms in source, or would likely only be
useful if leverage the speed of being a compiled internal "function" (algorithm)
are:

GCD (HCF)
LCM
https://www.geeksforgeeks.org/mathematical-algorithms/mathematical-algorithms-gcd-lcm/

! factorial

Strangely, sgn (N) is not inbuilt.

And I guess until I run into something else, that's it for today's installment.
 :)

- BW

[William F Pokorny] Re: yuqk feature requests / suggestions [832 days and 7 minutes ago]

Tue, 2 Jan 2024 16:00:33 GMT

On 1/2/24 07:34, Bald Eagle wrote:
> Rather than puzzling out single-use formulas for doing such a conversion, it
> would be extremely convenient, especially to new users, to have a set if inbuilt
> functions specifically for this purpose.
> 
> A basic set of formulas, proposed by Freya Holmer
> https://www.youtube.com/watch?v=NzjF1pdlK7Y
> is suggested for use below:
> //------------------------------------------------------------------------
> 
> // Freya Holmer
> #declare Lerp    = function (Start, End, Value) {(1 - Value) * Start + (End *
> Value)}
> 
> #declare InvLerp = function (Start, End, Value) {(Value - Start) / (End -
> Start)}
> 
> #declare ReMap   = function (OldMin, OldMax, NewMin, NewMax, Value) {Lerp
> (NewMin, NewMax, InvLerp (OldMin, OldMax, Value) )}
> 
> //------------------------------------------------------------------------
> 
> While hunting down this code, I found a functions.inc file by WFP that had some
> internal remapping functions (presumably for use in isosurfaces in povr/yuqk)
> but the accompanying documentation was pretty complex, dense and hard to follow,
> but it suggests that there are other remapping schemes may be desirable.

Yuqk's functions.inc documents a f_range2range() inbuilt which is likely 
equivalent to the the 'Remap' function above - though the value is the 
first parameter rather than the last.

Yes, yuqk's f_remap() is somewhat complicated. It could be used for one 
range to range pair, but it's aimed more at creating multiple roots 
(more particularly, isosurface shells) at particular value locations 
within an existing functions value's overall range. For example, 
multiple shells within f_sphere()'s return values where we'd normally be 
able to create only one shell about f_sphere()'s radius value / single 
root.

Providing inbuilt function(s?) for common interpolation methods is a 
good idea. Some time ago Ingo coded up an include with a largish set of 
gradients / interpolation methods. My aim is to someday create a 
f_interpolation() inbuilt which encapsulated most (or all?) of those and 
probably others. Maybe I'll at least create an initial version when I go 
after those additional 3x, 21 bit float functions...

I have started a directory of examples for the inbuilt functions which 
is shipped in the examples tar ball. Overall progress is admittedly slow.

Aside: I have large collection of scene files for playing with / testing 
the inbuilt functions, but those are mostly not good examples as coded. 
Plus, quite a few no longer work because of later yuqk changes...

Aside: The functions.inc file has a self test section at the bottom with 
the functions coded up for sanity testing purposes. That testing code 
sometimes works as decent example code.

Anyhow. In general, I agree with the suggestions in your post! :-)

Bill P.

[Bald Eagle] Re: yuqk feature requests / suggestions [832 days 3 hours and 33 minutes ago]

Tue, 2 Jan 2024 12:35:00 GMT

With regard to recent work by Jonathan Bush,

It occurred to me that a fairly typical and frequently used operation in
constructing scene code is the remapping of a value in one domain to a value in
another domain (typically 0 to 1).

Rather than puzzling out single-use formulas for doing such a conversion, it
would be extremely convenient, especially to new users, to have a set if inbuilt
functions specifically for this purpose.

A basic set of formulas, proposed by Freya Holmer
https://www.youtube.com/watch?v=NzjF1pdlK7Y
is suggested for use below:
//------------------------------------------------------------------------

// Freya Holmer
#declare Lerp    = function (Start, End, Value) {(1 - Value) * Start + (End *
Value)}

#declare InvLerp = function (Start, End, Value) {(Value - Start) / (End -
Start)}

#declare ReMap   = function (OldMin, OldMax, NewMin, NewMax, Value) {Lerp
(NewMin, NewMax, InvLerp (OldMin, OldMax, Value) )}

//------------------------------------------------------------------------

While hunting down this code, I found a functions.inc file by WFP that had some
internal remapping functions (presumably for use in isosurfaces in povr/yuqk)
but the accompanying documentation was pretty complex, dense and hard to follow,
but it suggests that there are other remapping schemes may be desirable.

Similarly, an example scene to demonstrate/illustrate how <u, v> values get
remapped to <x, y, z> values on a parametric surface would likely be of interest
and use to those trying to understand how uv-mapping works.

Also, IIRC, there is some spline-based animation code, perhaps written by Rune
Johansen that employs some extensive remapping functions.

The point of this thread being that certain operations widely considered to be
basic operations in computer graphics should be inbuilt in yuqk / 4.0 rather
than require an awareness of multiple include files and other external libraries
by users as part of the rather steep learning curve.
Also, the power and speed of compiled source code, and the algorithmic nature of
source-code "functions" would reduce significant frustration in trying to write
complex scene code, and make POV-Ray more attractive and competetive in the
larger computer graphics community.

- BW

[Bald Eagle] Re: yuqk feature requests / suggestions [836 days 20 hours and 8 minutes ago]

Thu, 28 Dec 2023 20:00:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/27/23 18:44, Tor Olav Kristensen wrote:
> > I'm sorry Bill, but you have to provide some more information for us about
> > what you are doing here.

https://arxiv.org/pdf/1511.04224.pdf

I was working on figuring out Stephen Marschner's procedural wood texture, and
part of the paper uses triangular waves and rectangular waves with specific
properties, as he states:

6.1.3 Seasonal growth
We turn the r coordinate volume into a time volume by scal-
ing its value and adding a smoothed triangular wave w (r)
to it. Each cycle of the smoothed triangle wave consists of
two linear segments connected by quadratic segments so as
to make the wave C1 continuous. The parameters are the
lengths of the two linear segments and the two quadratic
segments.
We scale the triangle wave so that when added to the radius,
half of the time the wood grows faster than the mean and
half of the time the wood grows more slowly. Then we add
1D noise n to generate variation in growth rate. All in all,
we have
tpre = r + w (r) (23)
t = tpre + n (tpre) (24)
This gives us the time at which any point in the wood was
laid down.
6.1.4 Growth rings
We can then create growth rings from the time volume. By
using a smoothed rectangular wave g = w (t), we can vary
the absorption of the wood according to the season. Simi-
larly to the triangle wave used to determine the growth rate,
each cycle of the smoothed rectangular wave consists of two
constant segments and two cubic segements so as to make
the wave C2 continuous, and the parameters are the relative
lengths of the two linear segments and the two quadratic
segments, plus the minimum and maximum values.

- BW

[William F Pokorny] Re: yuqk feature requests / suggestions [836 days 22 hours ago]

Thu, 28 Dec 2023 18:07:38 GMT

On 12/27/23 18:44, Tor Olav Kristensen wrote:
> I'm sorry Bill, but you have to provide some more information for us about
> what you are doing here.

Bill posted a test scene here:

http://news.povray.org/povray.bugreports/thread/%3Cweb.654c1b56f53b6bed1f9dae3025979125%40news.povray.org%3E/

I've not gotten around to looking at it myself, but it is on my to do 
list somewhere.

---

FYI. With credit, I've added the bottom part of your response - on the 
zero bucketing adjustments - to yuqk's select keyword documentation.

Bill P.

[William F Pokorny] Re: yuqk feature requests / suggestions [836 days 22 hours and 11 minutes ago]

Thu, 28 Dec 2023 17:56:42 GMT

On 12/27/23 19:13, Tor Olav Kristensen wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>>> Assuming you want access to the real internally generated >first rays,
>>
>> Nope.
>> Just something like:
>>
>> #declare SFn_vdot = function (ax, ay, az, bx, by, bz) {ax*bx + ay*by + az*bz}
>>
>> #declare f_Reflectionx = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dx - 2 * SFn_vdot
>> (Dx, Dy, Dz, Nx, Ny, Nz)* Nx}
>> #declare f_Reflectiony = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dy - 2 * SFn_vdot
>> (Dx, Dy, Dz, Nx, Ny, Nz)* Ny}
>> #declare f_Reflectionz = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dz - 2 * SFn_vdot
>> (Dx, Dy, Dz, Nx, Ny, Nz)* Nz}
>> ...
> 
> You are already thinking in the right ways...
> To see how you can use that further, have a look here:
> 
> Subject: Source code for "With and without a light_source"
> From: Tor Olav Kristensen
> Date: 2003-06-23 18:20:41
>
https://news.povray.org/povray.text.scene-files/message/%3CXns93A54E262AE2torolavkhotmailcom%40204.213.191.226%3E
> 
> There's no vector cross expressions there. But that will require only 3 small
> exressions.
> 
> --
> Tor Olav
> http://subcube.com
> https://github.com/t-o-k
> 
> 

OK. When I get to implementing 21 bit float dot, cross functions for 
yuqk, I'll think about reflection / refraction functions too. I already 
implemented a f_normal() function and have had thoughts on perhaps 
implementing some sort of pre-range, bounded, f_trace() 'trace()' 
equivalent too, but we'll see...

Bill P.

[Tor Olav Kristensen] Re: yuqk feature requests / suggestions [837 days 15 hours and 38 minutes ago]

Thu, 28 Dec 2023 00:30:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> With regard to the current shader, I've run into quite a number of stumbling
> blocks that highlight the deeply ingrained problems and limitations of the
> function parser.  I'm not saying that Thorsten didn't do a good job - it's just
> that what we have isn't really adequate to the tasks I would (reasonably) like
> to accomplish, and isn't conducive to moving forward toward 4.0.
>
> When evaluating a pattern, things need to be coded in a certain "static" way.
> What one might do in a macro - declaring variables to store intermediate
> calculation results - isn't possible with functions.
>...

To not have variables in functions is not necessarily a showstopper.

It just requires you to rewire your brain to program in a more "functional" way.
    ;-)
A lot of people struggle with this when they start programming in functional
languages.

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

[Tor Olav Kristensen] Re: yuqk feature requests / suggestions [837 days 15 hours and 53 minutes ago]

Thu, 28 Dec 2023 00:15:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > Assuming you want access to the real internally generated >first rays,
>
> Nope.
> Just something like:
>
> #declare SFn_vdot = function (ax, ay, az, bx, by, bz) {ax*bx + ay*by + az*bz}
>
> #declare f_Reflectionx = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dx - 2 * SFn_vdot
> (Dx, Dy, Dz, Nx, Ny, Nz)* Nx}
> #declare f_Reflectiony = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dy - 2 * SFn_vdot
> (Dx, Dy, Dz, Nx, Ny, Nz)* Ny}
> #declare f_Reflectionz = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dz - 2 * SFn_vdot
> (Dx, Dy, Dz, Nx, Ny, Nz)* Nz}
>...

You are already thinking in the right ways...
To see how you can use that further, have a look here:

Subject: Source code for "With and without a light_source"
From: Tor Olav Kristensen
Date: 2003-06-23 18:20:41
https://news.povray.org/povray.text.scene-files/message/%3CXns93A54E262AE2torolavkhotmailcom%40204.213.191.226%3E

There's no vector cross expressions there. But that will require only 3 small
exressions.

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

[Tor Olav Kristensen] Re: yuqk feature requests / suggestions [837 days 16 hours and 18 minutes ago]

Wed, 27 Dec 2023 23:50:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I figure I'll put this here, rather than embedding it in the midst of other
> threads.
>
> I'm currently working out some code to create some piece-wise functions with
> very specific constraints.
>
> During development, I noticed some odd mismatches, seemingly resulting from the
> manner in which 3-argument select () statements work.
>
> Using the 4-argument form and (repeating the equation to evaluate after a comma)
> doesn't seem to correct this.
>
> Specifically, each section of the piece-wise function never reaches the end of
> its domain, and instead, the next section of the nested select statement starts
> getting evaluated.
> I shifted the 2nd segment up a bit to illustrate the problem in the attached
> image. (disregard the file name)

I'm sorry Bill, but you have to provide some more information for us about
what you are doing here.


> https://wiki.povray.org/content/Reference:Numeric_Expressions
> select(A, B, C [,D])
> It can be used with three or four parameters Select compares the first argument
> with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
> floats or fun(c)tions.
> When used with three parameters, if A < 0 it will return B, else C (A >= 0).
> When used with four parameters, if A < 0 it will return B. If A = 0 it will
> return C. Else it will return D (A > 0).
>
>
>
> Maybe that's something that I'm doing wrong, or maybe there's a hidden issue
> with select () that's never been uncovered yet.
>...
> But it did make me think that there ought to be a way to reverse which "side" of
> the evaluation A = 0 gets included in:
>...

There already is a way:

select(A, B, C)

    A < 0: return B
    A = 0: return C
    A > 0: return C

select(-A, C, B)

    A < 0: return B
    A = 0: return B
    A > 0: return C

select(E - F, G, H)

    E < F: return G
    E = F: return H
    E > F: return H

select(F - E, H, G)

    E < F: return G
    E = F: return G
    E > F: return H


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

[Tor Olav Kristensen] Re: yuqk feature requests / suggestions [837 days 16 hours and 48 minutes ago]

Wed, 27 Dec 2023 23:20:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> Fundamental computer graphics functions like inbuilt vlength () doesn't work.
>...

For that you can use f_r() inside your own functions.

It's in functions.inc. It calls internal function no. 57.

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

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

[Bald Eagle] Re: yuqk feature requests / suggestions [838 days 1 hour and 58 minutes ago]

Wed, 27 Dec 2023 14:10:00 GMT

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

> Assuming you want access to the real internally generated >first rays,

Nope.
Just something like:

#declare SFn_vdot = function (ax, ay, az, bx, by, bz) {ax*bx + ay*by + az*bz}

#declare f_Reflectionx = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dx - 2 * SFn_vdot
(Dx, Dy, Dz, Nx, Ny, Nz)* Nx}
#declare f_Reflectiony = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dy - 2 * SFn_vdot
(Dx, Dy, Dz, Nx, Ny, Nz)* Ny}
#declare f_Reflectionz = function (Dx, Dy, Dz, Nx, Ny, Nz) {Dz - 2 * SFn_vdot
(Dx, Dy, Dz, Nx, Ny, Nz)* Nz}

which in sane functions would like a macro formula:

#macro Reflection (Direction, Normal)
 // r=d-2(d·n)n
 //#local Refl = 2*Normal*(vdot(Normal, V)) - V;
 #local v_reflection = Direction - 2*vdot (Direction, Normal)*Normal;

 v_reflection

#end

> the other forms are quite a bit harder / uglier to do than is trace().
> Further, the results for other than initial / first rays are also
> tangled in render settings and options.

Oh, I can only imagine...  :O

[William F Pokorny] Re: yuqk feature requests / suggestions [838 days 17 hours and 54 minutes ago]

Tue, 26 Dec 2023 22:14:11 GMT

On 12/25/23 09:51, Bald Eagle wrote:
> In playing around with ray diagrams, it occurred to me that we have no inc-file
> or inbuilt reflected ray macro or function (that I know of).
> 
> Since we have trace () that also supplies a surface normal, a nice complement to
> that would be reflected_ray (Ray, SurfaceNormal).
> 

(or refracted, transmitted, media generated...)

I agree such capability would be useful(a) for diagrams - and probably 
mostly for debugging.

Assuming you want access to the real internally generated >first rays, 
the other forms are quite a bit harder / uglier to do than is trace(). 
Further, the results for other than initial / first rays are also 
tangled in render settings and options.

Bill P.

(a) - While doing the solver work back in 2017 /2018, I a couple times 
hacked in a capability to dump all the generated rays from single 
rendered pixels. The pixels were isolated by start/end column row 
command line flags (or ini settings). FWIW - It was hacked code and not 
SDL available functionality.

[Bald Eagle] Re: yuqk feature requests / suggestions [840 days 1 hour and 13 minutes ago]

Mon, 25 Dec 2023 14:55:00 GMT

In playing around with ray diagrams, it occurred to me that we have no inc-file
or inbuilt reflected ray macro or function (that I know of).

Since we have trace () that also supplies a surface normal, a nice complement to
that would be reflected_ray (Ray, SurfaceNormal).

-BE

[Bald Eagle] Re: yuqk feature requests / suggestions [846 days 3 hours and 48 minutes ago]

Tue, 19 Dec 2023 12:20:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:

Hi Jerome,

> You can always use a converter for STL from Ascii to Binary, it will be
> far simpler than having yet another extension of the parser, or even a
> dedicated parser. It's only once you have experimented handling the
> versatility of text input that you start to like strict binary encoding.

I'm not sure if I misunderstand you, or you misunderstand me.
I'd like for POV-Ray to be able to natively parse and implement a simple ASCII
stl file.

No one out there writes include files for POV-Ray in its mesh {} format.
But there are tens of thousands, if not millions or billions of stl files for
the exploding 3D printing community.
We don't currently have a modeler - but we have a ready made source of MODELS.
And obviously modelers to make stls.
Please tell me that I don't have to explain the obvious advantage of that any
more.

Being able to use an ASCII stl file by way of a simple #include statement would
be a profoundly useful tool for the user community.  And it would also act as a
tool to draw new users into POV-Ray, because we could make them aware of a new
(to them) tool that can digitally represent the model that they want to build,
or paint, or whatever.  More exposure = more users = more interest = more
exposure .... until we hit that threshold where some of the people who discover
POV-Ray _ARE_ software developers and we can get new people who are motivated
enough and competent enough to work on the source code.  And that brings along a
whole new source of new ideas and approaches to old problems that we may not
have thought of, and may not have been available until now.

> Somebody seems enthusiast about mesh... you have probably no idea yet of
> the nest of snakes you are to discover.

I'm not very enthusiastic about meshes (at the moment) but I do acknowledge that
there are good things about mathematical primitives - and severe limitations,
and the same goes for triangle meshes.

> mesh{} and mesh2{} are two syntax for the same final data structure, but
> the latter is far faster to parse when the number of points starts
> increasing, as the computation are in mesh2{}, whereas mesh{} just do it
> on the fly for you.

Yes Sir - I have coded scenes using both of those data structures, and so have
read (mostly) all of the applicable documentation.

> Never forget portability & universality. Povray could run on Amiga.

I'm not forgetting that at all.  At the same time, whether good or bad - the
Amiga days are long past, and if POV-Ray is to avoid stagnation and death, then
there needs to be a certain amount of innovation and modernization so that it
can leverage as much of the newer computer architecture developments as
possible.

I've learned a lot over the past 10 years, but I'm still not a computer science
major or software developer.  However, sometimes that's an advantage, because
I'm not restrained by any preconceived notion of "you can't do that!" and so I
find some crazy way to make things happen anyway.  ;)

I do understand that POV-Ray's primary means of rendering is not rasterization,
and does not rely primarily on triangles, but surely we may in some (other) way
take advantage of the massive parallel computing of GPUs.  I don't know what we
have in our codebase that would take advantage of that, but just experimenting
with the capability to access a GPU would be like tasting a new food.   Why do
it?  So that you know what it's like.  There's no other way to accomplish
gaining that knowledge.  Then you can proceed from there.  Maybe we like the
taste of GPU, maybe not.

I also stumble across all manner of ways that other people do things, and just
recently read of "just in time" compiling - so maybe that's something to discuss
for future development work.

(Good to see you again, we miss you here)

- BW

[William F Pokorny] Re: yuqk feature requests / suggestions [847 days 1 hour and 12 minutes ago]

Mon, 18 Dec 2023 14:56:05 GMT

On 11/14/23 14:36, Bald Eagle wrote:
> With regard to the current shader, I've run into quite a number of stumbling
> blocks that highlight the deeply ingrained problems and limitations of the
> function parser.  I'm not saying that Thorsten didn't do a good job - it's just
> that what we have isn't really adequate to the tasks I would (reasonably) like
> to accomplish, and isn't conducive to moving forward toward 4.0.
> 
> When evaluating a pattern, things need to be coded in a certain "static" way.
> What one might do in a macro - declaring variables to store intermediate
> calculation results - isn't possible with functions.
> Vector components are scalar values, but using Vector.x in a function argument
> isn't allowed.
> Fundamental computer graphics functions like inbuilt vlength () doesn't work.
> Dot product?  Cross product?  c'mon.
> We have "matrix" transforms, but we don't really have actual matrices that do
> matrixy things.  At the very least we ought to have a projection matrix, simple
> matrix multiplication, transpose, diagonal elements of square matrix, and a
> determinant function.

Jerome's response reminded your post was on my - respond to it 
eventually lists (along with your select() bug report).

I agree with a lot of what you wrote and to the degree I'm able to push 
yuqk in some of those directions - near term - and within the confines 
of the current VM(a) I will (or perhaps already have).

I've implemented an f_length() inbuilt function for example.

What I've not gotten around to since adding the 3 x 21 bit float 
encoding / decode inbuilt functions is a set of inbuilt dot, cross, 
length 21 bit inbuilt functions. I'll bump those up my to do list. It 
would enable certain kinds of vector play withing the confines of the 
current VM and 'function compiler'. The 21 bit float accuracy is plenty 
of accuracy for most color work, for example - though not of course for 
other work.

(a) - The current VM has limits sure, but I've also found it to be solid 
code. I'm comfortable building on top of it with now a large amount of 
work which didn't require some completely new VM implementation.

Aside: A couple years ago I spend some time looking into and thinking 
about alternate 'simple' VMs (of the C++ template driven kind which has 
been used to enable old game collections on VMs emulating ancient 
hardware) along with some sort of accompanying assembler. The latter 
would solve solve issues with respect to lack of user accessible 
intermediate storage, for example, with minimal perturbation of the 
current parser and SDL. Thought was the SDL parser bit would be very 
roughly #declare Fn = fasm { ... }. I also had the thought there is no 
real reason we could not have multiple VM implementations going at the 
same time too - perhaps some for very specialized work / existing work 
based upon certain existing alternate architectures. Yes, now thinking 
aloud / dreaming a bit. :-)

Bill P.

[Le Forgeron] Re: yuqk feature requests / suggestions [849 days 21 hours and 28 minutes ago]

Fri, 15 Dec 2023 18:40:05 GMT

Le 14/11/2023 Ã  20:36, Bald Eagle a Ã©crit :
 > William F Pokorny <ano### [at] anonymousorg> wrote:
 >
 >> - My direction with yuqk is generally away from larger extensions like
 >> this being jammed into the POV-Ray core code. They make for a mess as
 >> seen by the user and those supporting / changing the internal code.
 >
 > Sorry, my Man, but I must respectfully disagree.
 > I'm not talking about binary STL, I'm talking about ASCII STL, or "STLA"
 > https://paulbourke.net/dataformats/stl/
 >

You can always use a converter for STL from Ascii to Binary, it will be 
far simpler than having yet another extension of the parser, or even a 
dedicated parser. It's only once you have experimented handling the 
versatility of text input that you start to like strict binary encoding.

 > It's a sparrow's fart away from being a legit POV-Ray mesh {} 
definition, which
 > is why I said it would be _trivial_ to implement.
 > Copy mesh{} code, paste mesh {} code, edit mesh {} code.   Done.
 > Just rather than mesh {}, call it stl {}.

Somebody seems enthusiast about mesh... you have probably no idea yet of 
the nest of snakes you are to discover.

mesh{} and mesh2{} are two syntax for the same final data structure, but 
the latter is far faster to parse when the number of points starts 
increasing, as the computation are in mesh2{}, whereas mesh{} just do it 
on the fly for you.

 >
 > We can find faster, more versatile and agile ways to do things, and 
open up the
 > code base to further expansion by making the addition of code modules 
easier to
 > implement.
 >

Never forget portability & universality. Povray could run on Amiga.

[Bald Eagle] Re: yuqk feature requests / suggestions [880 days 20 hours and 28 minutes ago]

Tue, 14 Nov 2023 19:40:00 GMT

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

> - My direction with yuqk is generally away from larger extensions like
> this being jammed into the POV-Ray core code. They make for a mess as
> seen by the user and those supporting / changing the internal code.

Sorry, my Man, but I must respectfully disagree.
I'm not talking about binary STL, I'm talking about ASCII STL, or "STLA"
https://paulbourke.net/dataformats/stl/

It's a sparrow's fart away from being a legit POV-Ray mesh {} definition, which
is why I said it would be _trivial_ to implement.
Copy mesh{} code, paste mesh {} code, edit mesh {} code.   Done.
Just rather than mesh {}, call it stl {}.

> In some situations you can use an image_map created from a function as a
> function accessible array. There is an example of this in the
> histogram.pov file shipped now in the yuqk documentation tarball.

Yes, I have thought about doing that, but having the native capability rather
than a work-around would keep me focused, on task, and less closer to "complex
coding burnout".

> > Vector sizes and elements in things like prisms ought to be versatile and/or
> > standardized.  Having to convert points to a 2D vector is a PITA.
>
> The tuple / batch / bulk / list assignment methods are supposed to help
> some with this sort of vector type issue. Though I confess, I've not
> thought much about how to set it up efficiently / generally.

Being able to vector swizzle would solve a lot of the issue.
Doing it internally by just having the prism use regular 3D vectors, but only
using Vector.xz would work as well.

>
> #local V = <0,0,0>; // 3D vector
> #local <A,B> = V;   // Tuple method grabs first two elements of V

^^^ Very interesting.  I didn't know that was a valid construction.

> #local V = <A,B>;   // UV vector

#local V = V.xz;   would be the preferred embodiment.

With regard to the current shader, I've run into quite a number of stumbling
blocks that highlight the deeply ingrained problems and limitations of the
function parser.  I'm not saying that Thorsten didn't do a good job - it's just
that what we have isn't really adequate to the tasks I would (reasonably) like
to accomplish, and isn't conducive to moving forward toward 4.0.

When evaluating a pattern, things need to be coded in a certain "static" way.
What one might do in a macro - declaring variables to store intermediate
calculation results - isn't possible with functions.
Vector components are scalar values, but using Vector.x in a function argument
isn't allowed.
Fundamental computer graphics functions like inbuilt vlength () doesn't work.
Dot product?  Cross product?  c'mon.
We have "matrix" transforms, but we don't really have actual matrices that do
matrixy things.  At the very least we ought to have a projection matrix, simple
matrix multiplication, transpose, diagonal elements of square matrix, and a
determinant function.

I understand clipka's gripe that POV-Ray is a raytracer, and there are plenty of
3rd party software packages that can do x,y,and z ... but - to further address
your "complication" argument - I think that 4.0 ought to be able to natively
perform a lot of tasks that are fundamental mainstays in computer graphics and
gaming texts.

Yes, POV-Ray is a raytracer.  But if it chains itself to the mindset of early
90's CGI, then it's going to get neglected and buried.  People are going to be
discovering and implementing new and interesting things to do, and they're going
to want the capability to code it - in a sane, straightforward manner.

Thinking about features and ways to implement them will get us all to look at
the big picture and find a way to generalize a lot of the specialty code that
got written in fits and starts by 20 different people and just pasted onto the
existing code base.

We can find faster, more versatile and agile ways to do things, and open up the
code base to further expansion by making the addition of code modules easier to
implement.

- BW

[William F Pokorny] Re: yuqk feature requests / suggestions [881 days 2 hours and 53 minutes ago]

Tue, 14 Nov 2023 13:14:22 GMT

On 11/8/23 17:24, Bald Eagle wrote:
> I figure I'll put this here, rather than embedding it in the midst of other
> threads.

:-) The feature wish lists never get shorter. Elsewhere you'd mentioned 
stl import. I started a longer response there, but got side tracked.

The short version of it is:

- I believe hgpovray38 has a simple import method inbuilt today.

- My direction with yuqk is generally away from larger extensions like 
this being jammed into the POV-Ray core code. They make for a mess as 
seen by the user and those supporting / changing the internal code. I 
recently removed the julia_fractal shape, for example. We are not set up 
well for larger extensions except where they can be implemented as SDL 
coded includes or they work as inbuilt / user functions.

> 
> I'm currently working out some code to create some piece-wise functions with
> very specific constraints.
> 
> During development, I noticed some odd mismatches, seemingly resulting from the
> manner in which 3-argument select () statements work.
> 
> Using the 4-argument form and (repeating the equation to evaluate after a comma)
> doesn't seem to correct this.
> 
> Specifically, each section of the piece-wise function never reaches the end of
> its domain, and instead, the next section of the nested select statement starts
> getting evaluated.
> I shifted the 2nd segment up a bit to illustrate the problem in the attached
> image. (disregard the file name)
> 
> https://wiki.povray.org/content/Reference:Numeric_Expressions
> select(A, B, C [,D])
> It can be used with three or four parameters Select compares the first argument
> with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
> floats or fun(c)tions.
> When used with three parameters, if A < 0 it will return B, else C (A >= 0).
> When used with four parameters, if A < 0 it will return B. If A = 0 it will
> return C. Else it will return D (A > 0).
> 

On my list to look at your select questions / ideas in more detail. What 
always pops to my mind when folks mention select() and bugs is whether 
we are switching on signed zeros - my head just isn't immediately 
remembering enough to say more at the moment.

> 
> 
> Maybe that's something that I'm doing wrong, or maybe there's a hidden issue
> with select () that's never been uncovered yet.
> 
> But it did make me think that there ought to be a way to reverse which "side" of
> the evaluation A = 0 gets included in:
> 
> When used with three parameters (in the reverse case), if A <= 0 it will return
> B, else C (A > 0).
> 
> 
> Also, in past projects I have run into situations where I'd like to use matrix
> transforms but with variable arguments.
> 
> Exposure of the elements of a matrix to SDL would be helpful when trying to
> apply multiple matrix transforms to something and intermediate stages need to be
> debugged, or simple matrix calculations need to be performed, letting
> POV-Ray/yuqk do the heavy lifting.
> 
> Freya Holmer just put out another video on multiplying vectors, and mentioned
> how when working with octonions, simply swizzling vector components allowed
> rapid calculations to be performed using that "trick".
> 
> Vector swizzling (Vec.zxy) would be handy
> 
> Vector functions would be positively worth paying for.
> Both user-defined, and inbuilt.
> vectors allowed as arguments, vector components as arguments, and vector
> results.
> sin (<x, y, z>) ought to give me a result of <sin x, sin y, sin z>
> 
> Allowing arrays to be referenced or processed by functions would be great as
> well.

A general capability not likely anytime soon.

I have added additional encodings into and out of a double's space to 
the yuqk fork. These effectively very tiny arrays which can be passed 
around in the parser and VM inside the double float space.

In some situations you can use an image_map created from a function as a 
function accessible array. There is an example of this in the 
histogram.pov file shipped now in the yuqk documentation tarball.

> 
> Vector sizes and elements in things like prisms ought to be versatile and/or
> standardized.  Having to convert points to a 2D vector is a PITA.
> 

The tuple / batch / bulk / list assignment methods are supposed to help 
some with this sort of vector type issue. Though I confess, I've not 
thought much about how to set it up efficiently / generally.

#local V = <0,0,0>; // 3D vector
#local <A,B> = V;   // Tuple method grabs first two elements of V
#local V = <A,B>;   // UV vector
prism {
   linear_spline
   0, 1, 10,
   V,
   ....

> Access to data types would be great.

The yuqk fork offers what is in setidtypes.inc.

> agnostic input data type for #read would be excellent as well.

Yeah, we really should be able to import STL with SDL itself...

> There's also the issue of determining the number of elements in a vector.

See setidtypes.inc

> 
> Lots of functions in math.inc that ought to be inbuilt.

I'd add shapes.inc, color.inc ...

Some of this has been done (see yuqk's math.inc), but yes, extending the 
core function set where we can makes sense.

> 
> Lots more I'm sure.  Don't worry, I'll think of them   ;)
> 
> - BW
>

[Bald Eagle] yuqk feature requests / suggestions [886 days 17 hours and 43 minutes ago]

Wed, 8 Nov 2023 22:25:00 GMT

I figure I'll put this here, rather than embedding it in the midst of other
threads.

I'm currently working out some code to create some piece-wise functions with
very specific constraints.

During development, I noticed some odd mismatches, seemingly resulting from the
manner in which 3-argument select () statements work.

Using the 4-argument form and (repeating the equation to evaluate after a comma)
doesn't seem to correct this.

Specifically, each section of the piece-wise function never reaches the end of
its domain, and instead, the next section of the nested select statement starts
getting evaluated.
I shifted the 2nd segment up a bit to illustrate the problem in the attached
image. (disregard the file name)

https://wiki.povray.org/content/Reference:Numeric_Expressions
select(A, B, C [,D])
It can be used with three or four parameters Select compares the first argument
with zero, depending on the outcome it will return B, C or D. A,B,C,D can be
floats or fun(c)tions.
When used with three parameters, if A < 0 it will return B, else C (A >= 0).
When used with four parameters, if A < 0 it will return B. If A = 0 it will
return C. Else it will return D (A > 0).



Maybe that's something that I'm doing wrong, or maybe there's a hidden issue
with select () that's never been uncovered yet.

But it did make me think that there ought to be a way to reverse which "side" of
the evaluation A = 0 gets included in:

When used with three parameters (in the reverse case), if A <= 0 it will return
B, else C (A > 0).


Also, in past projects I have run into situations where I'd like to use matrix
transforms but with variable arguments.

Exposure of the elements of a matrix to SDL would be helpful when trying to
apply multiple matrix transforms to something and intermediate stages need to be
debugged, or simple matrix calculations need to be performed, letting
POV-Ray/yuqk do the heavy lifting.

Freya Holmer just put out another video on multiplying vectors, and mentioned
how when working with octonions, simply swizzling vector components allowed
rapid calculations to be performed using that "trick".

Vector swizzling (Vec.zxy) would be handy

Vector functions would be positively worth paying for.
Both user-defined, and inbuilt.
vectors allowed as arguments, vector components as arguments, and vector
results.
sin (<x, y, z>) ought to give me a result of <sin x, sin y, sin z>

Allowing arrays to be referenced or processed by functions would be great as
well.

Vector sizes and elements in things like prisms ought to be versatile and/or
standardized.  Having to convert points to a 2D vector is a PITA.

Access to data types would be great.
agnostic input data type for #read would be excellent as well.
There's also the issue of determining the number of elements in a vector.

Lots of functions in math.inc that ought to be inbuilt.

Lots more I'm sure.  Don't worry, I'll think of them   ;)

- BW

[William F Pokorny] Re: jr's large csv and dictionary segfault in th... [919 days 3 hours and 45 minutes ago]

Sat, 7 Oct 2023 12:22:55 GMT

On 10/4/23 06:50, William F Pokorny wrote:
> The new bit I see is an existing, macro local, identifier changing type 
> from a 3D vector to a float - while the internal macro loops run. This, 
> of course, shouldn't happen and I still don't know why it is.

OK. I finally ran this bug down!

For any POV-Ray fork, or official release, using clipka's newer 
parser(*), change the line

	int Temp_Count=3000000;

to 	

	POV_LONG Temp_Count=9223372036854775807-1;

in the file parser.cpp and within Parser::Parse_RValue(...).

--- More detail for those interested.

There is code which counts the delta in the number of tokens found after 
seeing callable Identifiers / macro parameters. It involves the variable 
Tmp_Count. A variable I suspect was long ago initialized to a value 
thought to be many times larger than probable configuration values for 
TOKEN_OVERFLOW_RESET_COUNT.

The original coders made use of the token counter used for periodic 
parser status messages, rather than the global token counter, when 
calculating the delta in tokens parsed. This approach a little ugly in 
that it requires extra code for handling the reset/wrap cases which will 
frequently happen when TOKEN_OVERFLOW_RESET_COUNT is relatively small.

Christoph, while otherwise nicely re-factoring / cleaning up the older 
parser code, switched to using the global token counter straight up. 
This global counter has values which often run over/past the default 
Tmp_Count initialization of three million.

So... Once in a thousand blue moons, we call the 
Parser::Parse_RValue(...) code when the global token count is exactly 
three million and the delta in tokens found happens to be one.

On stepping on that landmine, code which should not run, does. This 
almost always results in an update to the wrong identifier type and a 
corruption of identifier associated data too.

A hideous bug. It's likely we didn't always know we'd tripped it. Only 
when the parser core dumped or stopped on some parser error was it clear 
something had gone wrong. I expect we all too often got weird parsing 
behavior or an odd image result instead. On thinking it something we 
did, we'd twiddle with the SDL. With the updated SDL and the bug would 
go away - or worse perhaps moves to another identifier with different 
end effects.

Further, where the parser didn't stop, the issue would often self heal 
the next time the identifier was redefined / updated (as in a loop) 
because the parser would realize the assigned value was indeed, say a 
vector, and not a float or whatever...

Animations - especially ones growing / changing frame to frame - are 
more likely to trip this bug simply for having more chances at it.

I was wrong that slowing down the parsing helped with this bug. I was 
simply changing the SDL parser's token counts enough to avoid it.

Bill P.

(*) - The v3.8 beta code backed off to an older v3.7 / v3.8 version of 
the parser which still used the token counter used for parser message 
updates regarding how many tokens have been parsed thus far. It should 
be OK with default builds excepting a couple VERY narrow exposures.

That said, I'd recommend all official code make the update above too! 
The v3.8 beta 1&2 code (and I'd bet most official POV-Ray versions...) 
are narrowly exposed:

- Should builders twiddle with the configuration variable 
TOKEN_OVERFLOW_RESET_COUNT in unlucky ways.

- Should the token delta count align in on an unfortunate harmonic with 
the relatively low default value of 2500 for TOKEN_OVERFLOW_RESET_COUNT. 
I think this not likely to happen in typical SDL.

- Should the type cast from the master POV_LONG (long long int) token 
count to 'int' itself cause a another problem - or still trigger this 
one in some round about way.

[jr] Re: jr's large csv and dictionary segfault in th... [919 days 22 hours and 58 minutes ago]

Fri, 6 Oct 2023 17:10:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 10/4/23 11:36, jr wrote:
> > out of interest, do macros and their respective local storage form units
> Suppose more the latter. There isn't really local macro storage / or a
> local macro stack (excepting where VM functions are used with macros).

hey, thanks.

makes one speculate that sometimes then perpaps it's something "silly", like
some pointer not updated (or incorrectly).


> ...
> identifier is seen as already defined locally... In other words, those
> #declares don't create new 'global' identifiers, but rather, they
> redefine the locally defined identifier.
> What this means more generally is we cannot arbitrarily create an
> identifier in the global name space with #declare where it has first
> been defined (added to the symbol table) with #local in the local macro
> space.

interesting, thanks.  (I get much good info from your "musings" :-))


regards, jr.

[William F Pokorny] Re: jr's large csv and dictionary segfault in th... [921 days 21 hours and 56 minutes ago]

Wed, 4 Oct 2023 18:12:02 GMT

On 10/4/23 11:36, jr wrote:
> out of interest, do macros and their respective local storage form units
> ("objects"), or are they married up "on demand" ?

Suppose more the latter. There isn't really local macro storage / or a 
local macro stack (excepting where VM functions are used with macros).

My current understanding; Hopefully not too badly described.

There is a, local to each macro when running, symbol table for #local 
declared things (*,**) and parameters (always true..?). The table 
entries point to created / stored things which might or might not 
persist beyond the macro call depending on whether they are assigned to 
an identifier in a calling level of hierarchy(b).

---
Function calls, whether inside or outside macros, are different.

For inbuilt functions like f_sphere() there is a virtual machine (VM) 
stack for passed and returned variables for each function call - and 
another stack used by the compiler for C++ variables within the inbuilt 
code.

For user (parse time compiled functions) run on the VM there is just the 
(VM) stack (lies and more lies... I know) from the SDL user's perspective.

Bill P.

(*) - Something I noticed on starting this recent debugging and that 
I've fixed in my povr copies of the HF* macros! These old HF* macros 
switch from using #local to using #declare for some variables near the 
bottom of each macro for reasons unknown...

...
-            #declare PArr[J][K] = P + H*Dir*Depth;
+            #local PArr[J][K] = P + H*Dir*Depth;

-            #declare K = K+1;
+            #local K = K+1;
          #end
-        #declare J = J+1;
+        #local J = J+1;
      #end

      HFCreate_()
...

This makes for confusing code, but it doesn't break things because the 
identifier is seen as already defined locally... In other words, those 
#declares don't create new 'global' identifiers, but rather, they 
redefine the locally defined identifier.

What this means more generally is we cannot arbitrarily create an 
identifier in the global name space with #declare where it has first 
been defined (added to the symbol table) with #local in the local macro 
space.

(**) - Something foggy still for me. I 'believe' it is still true that 
#local definitions sitting unwrapped by a macro in the top level scene 
file act as global #declares, but, I've not tested this with the new 
local and global dictionary access qualifiers in v3.8. Maybe at the top 
scene file the local and global dictionaries become the same thing?

[jr] Re: jr's large csv and dictionary segfault in th... [922 days and 28 minutes ago]

Wed, 4 Oct 2023 15:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/26/23 02:46, William F Pokorny wrote:
> > A status update.
> ...
> The new bit I see is an existing, macro local, identifier changing type
> from a 3D vector to a float - while the internal macro loops run. This,
> of course, shouldn't happen and I still don't know why it is.

still, (much) more information than before.  nice.


> There's a good deal of expression parsing going on in the loops -
> especially '.' vector element accesses. Most of that parsing being in
> the parser code, but some of it is happening in the VM too due a
> function call. Thinking aloud...

out of interest, do macros and their respective local storage form units
("objects"), or are they married up "on demand" ?


regards, jr.

[William F Pokorny] Re: jr's large csv and dictionary segfault in th... [922 days 5 hours and 18 minutes ago]

Wed, 4 Oct 2023 10:50:02 GMT

On 3/26/23 02:46, William F Pokorny wrote:
> A status update.

FWIW. Another status update ahead of some time away.

---
As I was running test cases ahead of another povr tarball release, I 
started getting a parse error from inside the HF_Torus() macro on a test 
case running cleanly for years.

The failing behavior, and tendency to run cleanly again on most any SDL 
change slowing down the parsing is similar to the issue in this thread.

The new bit I see is an existing, macro local, identifier changing type 
from a 3D vector to a float - while the internal macro loops run. This, 
of course, shouldn't happen and I still don't know why it is.

There's a good deal of expression parsing going on in the loops - 
especially '.' vector element accesses. Most of that parsing being in 
the parser code, but some of it is happening in the VM too due a 
function call. Thinking aloud...

Bill P.

[jr] Re: jr's large csv and dictionary segfault in th... [1113 days 22 hours and 28 minutes ago]

Sun, 26 Mar 2023 17:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Aside: I've gotten another two complete povr animation passes through
> with those changes to foreach.inc. Magic, but still real magic! FWIW. :-)

quick <blush> in public..  :-)


regards, jr.

[William F Pokorny] Re: jr's large csv and dictionary segfault in th... [1114 days 2 hours and 21 minutes ago]

Sun, 26 Mar 2023 13:47:08 GMT

On 3/26/23 05:55, jr wrote:
> wondering whether it's possible we're "out-running" the (C++) garbage collector,
> and when the macro is called, it then sees "inappropriate" memory on occasion?

There isn't a garbage collector in C++/C. Memory is allocated when 
needed and released when no longer needed.

Your question thought still a good one. It takes considerable time to 
walk through all the allocations and free them more or less unwinding 
all the allocations(a). It should be nothing new parser related proceeds 
until the memory is freed, but...

Today the memory free up and re-allocation happens in a big way when we 
move frame to frame in an animation because one parsing thread goes 
away(a) and another gets created for the next frame. Parsing itself is 
always single threaded, unlike most other parts of POV-Ray, so we should 
not see multi-threading issues per-se.

What I too suspect is that we are perhaps sometimes seeing not quite (or 
perhaps in-correctly) initialized new parser memory that still contains 
data from the previous parser thread. This could explain why once we see 
fail points, they sometimes repeat that fail signature for a while.

Aside: I've gotten another two complete povr animation passes through 
with those changes to foreach.inc. Magic, but still real magic! FWIW. :-)

Bill P.

(a) - Back in my working years we were using a large, internally 
developed, interactive tool. On it's conversion to C++ we got frustrated 
because it took forever to exit the application as the memory was 
painstakingly released bit by bit. The developers solved the problem by 
intentionally crashing out of the application and letting the OS clean 
up the process related memory! ;-)

Anyhow. There is a performance cost to maintaining a, sort of, minimum 
memory foot print over time (as there is too for garbage collection 
memory management when it kicks in). I've wondered how much time we are 
burning doing memory management alone. Plus C++, because it tends to 
allocate as needed, ends up with bits and pieces of things all over the 
place in physical memory where it would be much better for performance 
if related memory were allocated (or re-allocated) in big contiguous 
blocks. Newer C++ versions have features intended to help with this 
memory fragmentation issue. Ah, whatever I guess. All still well down on 
my todo / toplaywith list.

[jr] Re: jr's large csv and dictionary segfault in th... [1114 days 6 hours and 8 minutes ago]

Sun, 26 Mar 2023 10:00:00 GMT

hi,

will (have to) re-read the whole post later.

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> The segfault comes and goes ...
> The really odd fails seen, ...
> thought for a while it was file I/O issue, but one fail on the macro
> string checking suggests it does have something to do with the
> dictionaries or the dictionary set up as you, jr, suspected.

wondering whether it's possible we're "out-running" the (C++) garbage collector,
and when the macro is called, it then sees "inappropriate" memory on occasion?

regards, jr.

[William F Pokorny] jr's large csv and dictionary segfault in the po... [1114 days 9 hours and 21 minutes ago]

Sun, 26 Mar 2023 06:46:56 GMT

A status update.

---
First, let me put on the table the segfault which happens here should 
not be a segfault during a non-debug run! Someone had already added code 
comments in the cylinder and code code to this effect.

It's good fortune - of sorts - we get the segfaults in povr, but it's 
only happening because no POV-Ray source coder got around to changing 
that throw into a warning or possible error message. ;-)

---
I've had no luck finding the core problem.

The segfault comes and goes depending seemingly on a lot of things - 
which makes me wonder if it isn't sitting there in official POV-Ray 
releases too and we've just not tripped it.

The really odd fails seen, I've been unable to reproduce even once. At 
the moment I'm chalking those up to my fatigue and potential 
configuration and set up issues as I tried to run through just parts of 
the animation.

---
I have now a changed foreach.inc file where I've added checks for 
duplicate macro to be executed strings and duplicate i_ indexes which 
has been working for me without fail for a while!

I suspect it's because I've slowed an whole animation down to almost 
exactly the time it take p380 beta 2 to do it - and I've never seen a 
fail there either.

The code changed is now:

#macro fore_voidRun(a_)
   #for (i_, 0, dict_.ttl_ - 1)

     // After this in, not seen a fail myself.
     #ifndef (Last_i_)
         #declare Last_i_ = i_;
     #else
         #if (Last_i_=i_)
             #local DummyID = f_boom(9,8,7,6,5,4);
         #end
         #declare Last_i_ = i_;
     #end

     #if (i_)
       fore_cmdNext(dict_)
     #end
     #local cmd_ = fore_cmdStr();

     // Below code found a duplicate once - and only once.
     #ifndef (LastCmdStr)
         #declare LastCmdStr=cmd_
     #else
         #if (strcmp(LastCmdStr,cmd_)=0)
             #local DummyID = f_boom(1,2,3,4,5,6);
         #end
         #declare LastCmdStr=cmd_
     #end

     fore_exec(cmd_,"parse_fore_void.tmp")
     #if (fore_debug)
       #debug concat("called '",cmd_,"'.\n")
     #end
   #end
#end

So it feels like a race issue of some kind, but I cannot see how it can 
even come about... Each frame is indeed a new parser thread, but it 
should be nothing from the prior frame's thread carries forward. I 
thought for a while it was file I/O issue, but one fail on the macro 
string checking suggests it does have something to do with the 
dictionaries or the dictionary set up as you, jr, suspected.

---
On the animation itself. We are basically re-building the scene for each 
frame of the animation with early frames having very few objects and the 
last ones almost 9000. A curiosity I don't understand is the 
usaf__mkItems(4130,a_[4130],tmp_) package indexing goes well to values 
over 10000 on occasion. These often peak at those levels and then are 
not seen again - maybe these all come from the partial runs where the 
animation re-starts? Done so many of these things my head is mush on 
what's what.

Anyway, the who code set up, gets slower and slower as we get into the 
later frames. Some is because the parsing just gets big/long, but it's 
also because the dictionary gets slower. The dictionary is built on top 
of the parser symbol table mechanism and, while I've not dug to be 
certain, my bet is some of the chains hanging off the hash table entries 
are getting long and slow.

I don't know enough about what is changing in the animation to suggest 
it, but, if there are larger fixed portions on which we are building and 
building, it would almost certainly be faster to keep those fixed parts 
as larger include files we bring in all at once - as raw SDL.

Suppose the suggestion neither here or there with respect to the problem 
- which is certainly real.

I'll keep playing with it as I have time - and I feel like it - but 
given that even starting at say frame 3000 isn't saving me all that much 
time for each animation turn - this is a very painful bug to chase.

My plan at the moment is to kick off the full hour plus long animation 
(tiny image sizes) with the added delay in place - as I think to do it. 
At days end perhaps.

It's not failed in a long while for me, but it's slow even at tiny image 
sizes so I haven't really run that many full passes.

If it doesn't fail again for me over time - the delay / race condition 
idea perhaps holds enough water for me to start putting in random locks 
as I can maybe see places to insert them. The trouble has been that I 
perturb things and the the problem blinks in and out for I do not know 
what cause - if any really my doing. I cannot come up with a solid way 
to come at this problem! It's too flaky - and it takes a painful amount 
of time to try anything.

Yes, I'm whining now and should stop. :-)

Bill P.

[Kenneth] Re: povr features required in official [1136 days 19 hours and 48 minutes ago]

Fri, 3 Mar 2023 20:20:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/3/23 05:57, William F Pokorny wrote:
>
> First jitter must be on. This is me not remembering - and, IIRC, it is
> on by default with recent POV-Ray releases, but not in povr.
>
Yes, in the Windows version the AA jitter is on by default.
>
> Thank you, Kenneth, for straightening me out! :-) I've added some notes
> to the source to jog my memory down the road...
>
I'm glad that it helped!

[William F Pokorny] Re: povr features required in official [1137 days 2 hours and 32 minutes ago]

Fri, 3 Mar 2023 13:35:40 GMT

On 3/3/23 05:57, William F Pokorny wrote:
> OK. Thanks!
> 
> I'll put it on the list to again review in povr. I'd first noticed it 
> with povr's, again truly random jitter with and big jitter values (>1). 
> Maybe I did something which caused the problem while banging on code! Or 
> maybe the windows version is for some reason different - in official 
> POV-Ray code, RTR doesn't work on unix/linux machines.

Alright. I both didn't remember well and I never completely understood 
what was happening... This is only a povr big jitter +j(>1.0) issue.

First jitter must be on. This is me not remembering - and, IIRC, it is 
on by default with recent POV-Ray releases, but not in povr.

Plus! The user value must be larger than 1.0 for the issue to show 
itself - which can only happen with my povr branch. The official release 
jitter can only be on or off. Somewhere the jitter value is getting 
reset/restored to 1.0 after each RTR frame - though in a quick look I 
don't see where!

I too continue to get AA in all my RTR frames, but povr's big jitter 
goes to a value of 1.0 after the first frame.

Thank you, Kenneth, for straightening me out! :-) I've added some notes 
to the source to jog my memory down the road...

Bill P.

[William F Pokorny] Re: povr features required in official [1137 days 5 hours and 10 minutes ago]

Fri, 3 Mar 2023 10:57:43 GMT

On 3/3/23 03:38, Kenneth wrote:
>> Hmm. I'm pretty sure AA modes 1 & 2 stop working completely after frame
>> 2 or 3. It's running, but it doesn't do anything after a while because
>> the internal box sizes shrink on every recursion and never get reset.
> I had to double-check this, to prove it to myself ðŸ˜‰  It does
seem to be
> working OK.
> 
> I let my animation cycle for several minutes(!), with a '20-camera animation'.
> The attached images are screenshots of 'camera 19', then blown up 200%.

OK. Thanks!

I'll put it on the list to again review in povr. I'd first noticed it 
with povr's, again truly random jitter with and big jitter values (>1). 
Maybe I did something which caused the problem while banging on code! Or 
maybe the windows version is for some reason different - in official 
POV-Ray code, RTR doesn't work on unix/linux machines.

Hmm, I got the compiles set now to turn off the duplicate vector zeroing 
on allocation. Maybe the duplicate zeroing was covering some other 
behavior as I've found quite a few times already. To test such thoughts 
is why there is the povr configure option:

--enable-vector-zeroing enable old, nearly always unneeded vector zeroing.

Bill P.

[Kenneth] Re: povr features required in official [1137 days 7 hours and 13 minutes ago]

Fri, 3 Mar 2023 08:55:00 GMT

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> I let my animation cycle for several minutes(!), with a '20-camera animation'.
> The attached images are screenshots of 'camera 19', then blown up 200%.

Forgot to mention that the "CL" lettering in the images is not being
anti-aliased, by mistake; the reason is that I had set its texture{diffuse...}
value to 20, not 1...and anti-aliasing begins to fail with super-bright objects
>> 1.0

[Kenneth] Re: povr features required in official [1137 days 7 hours and 28 minutes ago]

Fri, 3 Mar 2023 08:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/1/23 23:12, Kenneth wrote:
> >
> > Just tested +kla +rtr, and AA does work with it.

> Hmm. I'm pretty sure AA modes 1 & 2 stop working completely after frame
> 2 or 3. It's running, but it doesn't do anything after a while because
> the internal box sizes shrink on every recursion and never get reset.

I had to double-check this, to prove it to myself ;-)  It does seem to be
working OK.

I let my animation cycle for several minutes(!), with a '20-camera animation'.
The attached images are screenshots of 'camera 19', then blown up 200%.
> >
> > The only trouble I'm currently having is getting the animation to stop!
>
> I 'think' more often with SDL1.2 than
> SDL2.0/X11 an on unix/linux the preview window needs to be in 'focus' /
> active.

That appears to help with the Windows version too, if the animation isn't
playing *super*-fast. Thanks.

[William F Pokorny] Re: povr features required in official [1137 days 17 hours and 46 minutes ago]

Thu, 2 Mar 2023 22:21:29 GMT

On 3/1/23 23:12, Kenneth wrote:
> Just tested +kla +rtr, and AA does work with it. It has been awhile since I used
> the real-time animation feature-- probably on an older Win 7 machine a couple of
> years ago.
Hmm. I'm pretty sure AA modes 1 & 2 stop working completely after frame 
2 or 3. It's running, but it doesn't do anything after a while because 
the internal box sizes shrink on every recursion and never get reset.

> 
> The only trouble I'm currently having is getting the animation to stop!

Yes, this seems to be a problem more so on windows than unix/linux but 
it happens there too sometimes. There is I believe a github issue open 
on the problem. Little bells... I 'think' more often with SDL1.2 than 
SDL2.0/X11 an on unix/linux the preview window needs to be in 'focus' / 
active.

With the povr branch I broke out the cylic control as it's own thing and 
the default is to run through the cameras only once. Also means +kla / 
clockless_animation now means 'clockless animation' and not 'cylic 
clockless animation'.

// Use +kc (Cyclic_Animation=true) for cylic / continuous renders
// looping through cameras.

Bill P.

[Kenneth] Re: povr features required in official [1138 days 11 hours and 53 minutes ago]

Thu, 2 Mar 2023 04:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/26/23 06:59, jr wrote:
>
> There were a couple of issues / bugs as I recall which are fixed in the
> povr source. First was that RTR_HACK didn't wrap all the rtr related
> code - why it appears to be there, but broken with unix compiles. There
> was too a bug where AA worked only for the first frame or two of an rtr
> animation - true no matter the Operating System. Might be some other
> stuff, but nothing popping into my head.
>

[Windows 10, and using v3.8.0 beta 1, already compiled]:
Just tested +kla +rtr, and AA does work with it. It has been awhile since I used
the real-time animation feature-- probably on an older Win 7 machine a couple of
years ago.

The only trouble I'm currently having is getting the animation to stop! On my
newer and faster machine, hitting the GUI's 'stop' button sometimes works,
sometimes doesn't. It depends on how fast the animation is running. Shutting
down POV-ray is then the only way to end the process (AFTER hitting the stop
button repeatedly)-- otherwise, it would probably run until the year 10,191 :-O

Here's something subtle that I also just noticed: In this 'runaway' condition,
and after stabbing at the 'stop' button with no result, the animation will
sometimes suddenly speed up even faster(!). My machine's processor fan also
quiets down-- as if there is suddenly no more CPU-processing taking place. It's
like the animation is now simply playing back from a memory cache(?).

[William F Pokorny] Re: povr features required in official [1141 days 22 hours and 38 minutes ago]

Sun, 26 Feb 2023 17:29:43 GMT

On 2/26/23 06:59, jr wrote:
> hi,
> 
> as per the subject, I have tried to .. brow-beat CC to consider some of the nice
> 'povr' features you added, when the opportunity arose talking about the
> broken-on-Linux RTR feature.
> 
> so, regarding RTR, I want to find out what (pretty much) exactly was the
> difference to the Windows version (and 'povr').  my guess was/is, essentially a
> pointer not pointing to the correct buffer, as everything appears to work except
> the preview window.

IIRC. The only thing you need to do to activate the existing rtr feature 
with 'unix' compiles in v3.8+ branches is to define a variable called 
RTR_HACK.

There were a couple of issues / bugs as I recall which are fixed in the 
povr source. First was that RTR_HACK didn't wrap all the rtr related 
code - why it appears to be there, but broken with unix compiles. There 
was too a bug where AA worked only for the first frame or two of an rtr 
animation - true no matter the Operating System. Might be some other 
stuff, but nothing popping into my head.

There is too a POV_RTR_DEBUG define - but I don't 'think' it currently 
used. It might be in certain sets of code.

The povr fork has gone on to add additional features as you know. All 
should be wrapped with RTR_HACK as in:

#ifdef RTR_HACK
...
#endif

> 
> have several more questions, but would (probably) prefer to ask those in
> private.
> 

I'll email you from my gmail account. I hardly use it these days, but it 
is the account where I've tried to keep most POV-Ray email.

Bill P.

[jr] povr features required in official [1142 days 4 hours and 8 minutes ago]

Sun, 26 Feb 2023 12:00:00 GMT

hi,

as per the subject, I have tried to .. brow-beat CC to consider some of the nice
'povr' features you added, when the opportunity arose talking about the
broken-on-Linux RTR feature.

so, regarding RTR, I want to find out what (pretty much) exactly was the
difference to the Windows version (and 'povr').  my guess was/is, essentially a
pointer not pointing to the correct buffer, as everything appears to work except
the preview window.

have several more questions, but would (probably) prefer to ask those in
private.


regards, jr.

[tglmoa] Uberpov for windows [1324 days and 53 minutes ago]

Sun, 28 Aug 2022 15:15:00 GMT

I am relearning POVray after a long hiatus. I used POVray and MegaPOV for Mac
way back when and am now learning POVray 3.7 and UberPOV for Windows. On Mac
both MegaPOV and UberPOV had a GUI for easy entry of various types of values.
I am not seeing this with Windows UberPOV. IS there any difference at all
between POVray and UberPOV? Forgive my ignorance as I been away from it for a
long time.

[Mr] Re: Hgpovray38, current state [1581 days 23 hours and 33 minutes ago]

Mon, 13 Dec 2021 16:35:00 GMT

Hi, I made a new attempt at building on Windows after changing one machine and a
fresh msvs install, (all configurations for vanilla pov built fine)  and noticed
one different warning about 'GetVersionExA' declared deprecated, from
pvupdate.cpp line 164, (microsoft error code C4996):

So I copied it here in case it might help solving windows build issues I met
before.

[clipka] Re: POV-Ray v3.8 backing up a bit [1752 days 18 hours and 26 minutes ago]

Fri, 25 Jun 2021 21:41:26 GMT

Am 25.06.2021 um 20:59 schrieb Dick Balaska:

> Bleh. I'll bet this breaks my SDL debugger
> ( https://www.buckosoft.com/qtpovray/debugger.html )
> which was a really simple hook into the new parser.

I take that as a compliment to the new parser's internal architecture.

Don't worry - once v3.8.0 is out, and work starts for good on its 
successor, the new parser will definitely be back on board.

(I'm tempted to try and work the new parser into a v3.8.1, but that may 
not necessarily happen. It all depends on how backward compatible I can 
make it behave.)

[Dick Balaska] Re: POV-Ray v3.8 backing up a bit [1752 days 21 hours and 8 minutes ago]

Fri, 25 Jun 2021 18:59:27 GMT

On 6/10/2021 5:47 AM, clipka wrote:
> Hi folks,
> 
> this is a heads-up for all of you who are faithfully working on 
> derivatives of POV-Ray - be it qtpovray, the mac port, or what-have-you.
> 
> We're currently preparing to enter the beta phase of POV-Ray v3.8; 
> however, in order to do so, we will _not_ continue from the current 
> master, but rather back up a bit, to the last commit before we 
> integrated the overhauled tokenizer/scanner into the parser. To help you 
> more easily find that commit in question (85db57d9), we've tagged it as:
> 

Bleh. I'll bet this breaks my SDL debugger
( https://www.buckosoft.com/qtpovray/debugger.html )
which was a really simple hook into the new parser.

-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[clipka] POV-Ray v3.8 backing up a bit [1768 days 6 hours and 21 minutes ago]

Thu, 10 Jun 2021 09:47:02 GMT

Hi folks,

this is a heads-up for all of you who are faithfully working on 
derivatives of POV-Ray - be it qtpovray, the mac port, or what-have-you.

We're currently preparing to enter the beta phase of POV-Ray v3.8; 
however, in order to do so, we will _not_ continue from the current 
master, but rather back up a bit, to the last commit before we 
integrated the overhauled tokenizer/scanner into the parser. To help you 
more easily find that commit in question (85db57d9), we've tagged it as:

     `nexus-v3.8-v4.0`

Also, v3.8 development will _not_ continue in the `master` branch, but 
rather a dedicated branch, `release/v3.8.0` (which already exists and is 
currently ahead of The Nexus, but will be backed up and branch off soon).

Note that besides reverting to the old parser, this will also revert 
back to the use of the boost-thread and boost-system libraries.


We recommend that you _do_ keep all the work you've done since The 
Nexus, as the current state of v3.8 will live on under the moniker v4.0.

There's nothing fundamentally wrong with the changes we introduced since 
The Nexus - we just won't be able to get them to a clean state as fast 
as we'd like to, and we'd probably have to break backward compatibility 
more than we'd be comfortable with in a v3.x release.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1779 days 19 hours and 19 minutes ago]

Sat, 29 May 2021 20:48:47 GMT

On 5/29/21 11:43 AM, jr wrote:
> so.  an include with one macro and version specific data, then?

Yeah, one could have a  macro - include which sets up an array of the 
values as they sit each version of code . Basically a bunch of calls to:

#macro Mcr_id_type(_id) id_type(_id) #end

setting up an array (or dictionary) which you'd then reference in 
compares to id_type() instead of calls to Mcr_id_type().

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1780 days and 23 minutes ago]

Sat, 29 May 2021 15:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/29/21 2:53 AM, jr wrote:
> > if that implies that the enumeration is sort of stable, perhaps it can be
> > "pressed into service"?
>
> It is in service with is_type(), but is itself not stable as keywords
> and keyword groupings change. Could an 'intended stable' form be created
> / maintained - sure. Is it worth the trouble - ehhh...

so.  an include with one macro and version specific data, then?


> ...
> As for what's playing in my head... A storm, always about three beats
> from incoherence. When I listen to music while coding, it's
> meaningful-vocal-less. Thinking, reading, coding in a public place where
> the sounds are a vibration, where only an occasional word or two pops to
> the surface, is best.

:-)  recognise the preference (?) for instrumentals.  (cannot usually relax
enough in a public place to .. let my mind wander)


regards, jr.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1780 days 2 hours and 51 minutes ago]

Sat, 29 May 2021 13:17:05 GMT

On 5/29/21 8:03 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> References to 'radio' will lead the kids reading to think we're ancient.
> 
> Just call it "wireless".  A term so old, its new again.
> 
...

Ah! We just have to apply enough spin... :-)

[Bald Eagle] Re: Initial povr branch keywords id_type() and i... [1780 days 4 hours and 3 minutes ago]

Sat, 29 May 2021 12:05:00 GMT

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

> References to 'radio' will lead the kids reading to think we're ancient.

Just call it "wireless".  A term so old, its new again.

> The youtube link was perhaps enough to fool em - that we're playing with
> POV-Ray won't help. ;-)

"More than just a pixel shader...."

> Anyhow. Let me know when I've gone over the edge - another one.

Don't call them "edges" - call them "new frontiers".

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1780 days 4 hours and 13 minutes ago]

Sat, 29 May 2021 11:54:53 GMT

On 5/29/21 2:53 AM, jr wrote:
> if that implies that the enumeration is sort of stable, perhaps it can be
> "pressed into service"?

It is in service with is_type(), but is itself not stable as keywords 
and keyword groupings change. Could an 'intended stable' form be created 
/ maintained - sure. Is it worth the trouble - ehhh...

> 
> re the 'is_type()' code -- SDL user me says "Yes".:-)   fwiw, I like this:
> 
>    #if (id_type(_mary[1]) != Mcr_id_type("Star dust falls"))
> 
> "idiom" a lot.
> 
> (also made me wonder what was playing on your radio while you wrote that code.
> UFO's "Prince Kajuku"??  "Catch a falling star put it in your pocket..."

References to 'radio' will lead the kids reading to think we're ancient. 
The youtube link was perhaps enough to fool em - that we're playing with 
POV-Ray won't help. ;-)

As for what's playing in my head... A storm, always about three beats 
from incoherence. When I listen to music while coding, it's 
meaningful-vocal-less. Thinking, reading, coding in a public place where 
the sounds are a vibration, where only an occasional word or two pops to 
the surface, is best.

Anyhow. Let me know when I've gone over the edge - another one. I'm 
still upright - I think.

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1780 days 9 hours and 13 minutes ago]

Sat, 29 May 2021 06:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 8:23 AM, jr wrote:
> > ...
> > thinking that if one (you :-)) were to set up an enum, ...
> Suppose it could be done by running a script to build such a cross index
> as a check in hook or something.
>
> There is today a basic enum to cross reference in the code that gets
> used when reporting messages and such. ...

if that implies that the enumeration is sort of stable, perhaps it can be
"pressed into service"?

re the 'is_type()' code -- SDL user me says "Yes".  :-)  fwiw, I like this:

  #if (id_type(_mary[1]) != Mcr_id_type("Star dust falls"))

"idiom" a lot.

(also made me wonder what was playing on your radio while you wrote that code.
UFO's "Prince Kajuku"??  "Catch a falling star put it in your pocket..."
<https://www.youtube.com/watch?v=KSBIDIZ6ySc> :-))

regards, jr.

[William F Pokorny] Re: vectors.inc Attn: Tor Olav (povr branch work) [1780 days 12 hours and 47 minutes ago]

Sat, 29 May 2021 03:21:03 GMT

On 5/28/21 9:41 PM, Bald Eagle wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> 
>> To fix this I would prefer to change the order of the "ifs" in the
>> OrthogonalVector() macro.
>>
>> If the old VPerp_To_Vector() macro is changed to call (wrap) the new
>> OrthogonalVector() with reordered "ifs", it will break scenes using the
>> VPerp_To_Vector() macro.
>>
>> So now I'm not sure what to do...
> 
> 2 things here:
> 
> 1.  I may be wrong, but I was under the impression that povr is a fork, and it's
> purpose is to improve and fix some longstanding issues with the official povray
> source code.  So breaking older scenes is probably not the primary concern.

Yes, the povr branch breaks what it needs to break to fix longstanding 
issues - and to evolve more radically(1). It's a big part of the aim of 
of it.  So yep, the change likely doesn't matter even if it does break 
something...

(1) - So I can try more of what I want to try... :-)

> 
> 2.  I thought that this was what the #version directive was for.  Can't you
> sniff the scene version and include a fork in the wrapper?   If the version is
> old, use the old way, and if it's new, use the new way?

I suppose, but I'm trying to avoid as much of that sort of thing as 
possible with povr. I've been ripping out backward compatibility stuff 
as I can for a long time now and there is still lots of it in there...

Rambling. At a high level I think about the ever backward comparability 
in POV-Ray proper and it's kind of amazing it's been kept up. I mean it 
all more or less works! For what I'm doing it's just not possible in 
many cases - hammer in hand, I'm  breaking stuff.

Bill P.

[William F Pokorny] Re: vectors.inc Attn: Tor Olav (povr branch work) [1780 days 13 hours ago]

Sat, 29 May 2021 03:07:58 GMT

On 5/28/21 6:53 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> OK, I think I've gotten your vectors.inc merged into - and alongside -
>> the core includes of my povr branch. With vectors.inc becoming one of
>> the core include files.
> 
> Good =)
> 
> 
>> Ended up... Sometimes wrapping macros in transforms.inc and math.inc to
>> call your versions. Sometimes leaving the existing, roughly-equivalent
>> macros but recommending your version in comments - and using yours over
>> the old versions otherwise in the core include files.
> 
> I'm a bit worried about the wrapping solution. That is because I'm contemplating
> a minor change in either the OrthogonalVector() macro or the
> AltOrthogonalVector() macro.
> 
> If one pass the same vector to both of these, I want the resulting vectors to
> always be orthogonal to each other in addition to being orthogonal to the
> vector passed to the macros.
> 
> Right now it is mostly so. But if if all the components in the passed vector are
> equal, this will not be the case (except for the case were the passed vector is
> the zero vector).
> 
> To fix this I would prefer to change the order of the "ifs" in the
> OrthogonalVector() macro.
> 
> If the old VPerp_To_Vector() macro is changed to call (wrap) the new
> OrthogonalVector() with reordered "ifs", it will break scenes using the
> VPerp_To_Vector() macro.
> 
> So now I'm not sure what to do...

Change your code as you'd most like.

Indeed, I now have in math.inc:

// Returns a vector perpendicular to V
// Author: Tor Olav Kristensen
// See: OrthogonalVector() and AltOrthogonalVector() in vectors.inc
#macro VPerp_To_Vector(v0)
   //#error "VPerp_To_Vector in math.inc called. Use OrthogonalVector()"
     OrthogonalVector(v0)
#end

If need be, I can restore the old code. However, I think you are talking 
about differences 'only' with <1,1,1>, <-1,-1,-1> and the like - yes? 
And given I suspect folks might occasionally use OrthogonalVector() with 
AltOrthogonalVector(), maybe the OrthogonalVector() as the 
VPerp_To_Vector result is ultimately better too even changed.

What kind of trouble might we get into if we leave the wrap post your 
changes... My gut says nothing practically, but I guess the ultra safe 
approach would be to revert VPerp_To_Vector() - but then povr has three...

In any case, I think doing what's ultimately best in vectors.inc is the 
way to go for the future.

> 
...
> 
> I tried to look for your new core include files at your github pages, but I
> could not find them there. Are they visible somewhere else ?
> 

I've been releasing occasional tarballs in povray.binaries.programming, 
but none of this work is posted as yet.

I'm under code control locally, but I don't yet want to put what I have 
out there as code controlled until my code is closer to I have in mind 
for the final form. I plan to initialize it anew at some point. An 
issues we have with the current POV-Ray git repositories is they are 
carrying around a huge history for what the povr core code base is.

> 
>> Only suggestion I'll make has to do with the documentation on your
>> github page at: ttps://github.com/t-o-k/Useful-POV-Ray-macros.
>>
>> With the VectorsFromTransform() and VectorsFromTransformFunction(),
>> where you are showing the initialization of v_X, v_Y, v_Z and p_T, ahead
>> of the macro calls; you could use the, new to v3.8, tuple initialization
>> syntax. For example:
>>
>> #declare (v_X,v_Y,v_Z,p_T) = (<0,0,0>,<0,0,0>,<0,0,0>,<0,0,0>);
> 
> I had forgotten about this new initialization type. I've now changed the
> examples to use it.
> 
> I've also changed the parameter names of the AccurateAngleBetweenVectors()
> macro, so that are in line with the names in the other macros.

Cool.

Something I forgot to say explicitly is povr is v3.8 parsing + povr 
changes. That said, often, straight v3.8 stuff runs and once I had all 
the test cases in place, I did run the testing with a pure v3.8 compile 
and all was OK.

Ya know... I was thinking only v3.8 when mentioning the tuple feature 
new to v3.8. I think you were aiming for v3.7 and v3.8 with vectors.inc 
and, if so, might be worth a footnote where you've used the tuple syntax 
saying that it's a v3.8 feature. Or go back to the v3.7 example. Always 
the details...

Bill P.

[Bald Eagle] Re: vectors.inc Attn: Tor Olav (povr branch work) [1780 days 14 hours and 23 minutes ago]

Sat, 29 May 2021 01:45:00 GMT

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> To fix this I would prefer to change the order of the "ifs" in the
> OrthogonalVector() macro.
>
> If the old VPerp_To_Vector() macro is changed to call (wrap) the new
> OrthogonalVector() with reordered "ifs", it will break scenes using the
> VPerp_To_Vector() macro.
>
> So now I'm not sure what to do...

2 things here:

1.  I may be wrong, but I was under the impression that povr is a fork, and it's
purpose is to improve and fix some longstanding issues with the official povray
source code.  So breaking older scenes is probably not the primary concern.

2.  I thought that this was what the #version directive was for.  Can't you
sniff the scene version and include a fork in the wrapper?   If the version is
old, use the old way, and if it's new, use the new way?

-Bill

[Tor Olav Kristensen] Re: vectors.inc Attn: Tor Olav (povr branch work) [1780 days 17 hours and 13 minutes ago]

Fri, 28 May 2021 22:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> OK, I think I've gotten your vectors.inc merged into - and alongside -
> the core includes of my povr branch. With vectors.inc becoming one of
> the core include files.

Good =)

> Ended up... Sometimes wrapping macros in transforms.inc and math.inc to
> call your versions. Sometimes leaving the existing, roughly-equivalent
> macros but recommending your version in comments - and using yours over
> the old versions otherwise in the core include files.

I'm a bit worried about the wrapping solution. That is because I'm contemplating
a minor change in either the OrthogonalVector() macro or the
AltOrthogonalVector() macro.

If one pass the same vector to both of these, I want the resulting vectors to
always be orthogonal to each other in addition to being orthogonal to the
vector passed to the macros.

Right now it is mostly so. But if if all the components in the passed vector are
equal, this will not be the case (except for the case were the passed vector is
the zero vector).

To fix this I would prefer to change the order of the "ifs" in the
OrthogonalVector() macro.

If the old VPerp_To_Vector() macro is changed to call (wrap) the new
OrthogonalVector() with reordered "ifs", it will break scenes using the
VPerp_To_Vector() macro.

So now I'm not sure what to do...

> As anticipated some minor changes in declared IDs due povr's lower case
> checking.
>
> Added basic self testing of all the macros as a block appended to the
> bottom.
>
> Turned out well. Thank you!

Thank you too !

I tried to look for your new core include files at your github pages, but I
could not find them there. Are they visible somewhere else ?

> Only suggestion I'll make has to do with the documentation on your
> github page at: ttps://github.com/t-o-k/Useful-POV-Ray-macros.
>
> With the VectorsFromTransform() and VectorsFromTransformFunction(),
> where you are showing the initialization of v_X, v_Y, v_Z and p_T, ahead
> of the macro calls; you could use the, new to v3.8, tuple initialization
> syntax. For example:
>
> #declare (v_X,v_Y,v_Z,p_T) = (<0,0,0>,<0,0,0>,<0,0,0>,<0,0,0>);

I had forgotten about this new initialization type. I've now changed the
examples to use it.

I've also changed the parameter names of the AccurateAngleBetweenVectors()
macro, so that are in line with the names in the other macros.

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

[William F Pokorny] vectors.inc Attn: Tor Olav (povr branch work) [1781 days 2 hours and 52 minutes ago]

Fri, 28 May 2021 13:16:07 GMT

OK, I think I've gotten your vectors.inc merged into - and alongside - 
the core includes of my povr branch. With vectors.inc becoming one of 
the core include files.

Ended up... Sometimes wrapping macros in transforms.inc and math.inc to 
call your versions. Sometimes leaving the existing, roughly-equivalent 
macros but recommending your version in comments - and using yours over 
the old versions otherwise in the core include files.

As anticipated some minor changes in declared IDs due povr's lower case 
checking.

Added basic self testing of all the macros as a block appended to the 
bottom.

Turned out well. Thank you!

Only suggestion I'll make has to do with the documentation on your 
github page at: ttps://github.com/t-o-k/Useful-POV-Ray-macros.

With the VectorsFromTransform() and VectorsFromTransformFunction(), 
where you are showing the initialization of v_X, v_Y, v_Z and p_T, ahead 
of the macro calls; you could use the, new to v3.8, tuple initialization 
syntax. For example:

#declare (v_X,v_Y,v_Z,p_T) = (<0,0,0>,<0,0,0>,<0,0,0>,<0,0,0>);

Bill P.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1781 days 2 hours and 55 minutes ago]

Fri, 28 May 2021 13:12:26 GMT

On 5/28/21 8:23 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/28/21 3:48 AM, jr wrote:
>>>> ...
>>>> What I've not done for arrays vs mixed arrays as yet is look for a
>>>> method 'like' that employed to break out a few of the object types like
>>>> light sources(1). The object flags popped into my head on Tor Olav's
>>>> question.
>>>
>>> I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
>>> and so perhaps a complementary function (eg) 'is_type_details()' which returns
>>> an array mixed, where the various flags are used to distinguish one ("390")
>>> object from another.
>>>
>>
>> Yes, is_type_details(), a possibility, but it would be work creeping
>> well past "easy."
>>
>> Aside: For the details which could be provided as strings of text as to
>> type, my thought was this work would be pushed onto users - or some
>> include file maintainer - in the form of a macro containing a big switch
>> kicking out text or setting up an array with, say, response strings:
>> "The is type passed to MagicMacro24 is a light_source."
> 
> I was about to suggest (almost) the opposite.  :-)
> 
> thinking that if one (you :-)) were to set up an enum, covering the basics
> (float, bool, vector, macro, function, array, string, such[*]), then changing
> (in the parser, between versions) ids could be "contained" in one mapping.  then
> 'is_type()', and later perhaps its companion func, would always provide
> consistent "numbers".  and yes, some include file to turn the numbers back into
> human speak would be v useful (will collaborate if thought helpful).
> 

Suppose it could be done by running a script to build such a cross index 
as a check in hook or something.

There is today a basic enum to cross reference in the code that gets 
used when reporting messages and such. We're basically talking about 
some parallel ID enum to locked integer index I guess - which 
is_type_details() or similar could use... I'll think about it, but at 
the moment it all feels a bit clunky /ugly given the minor value to end 
users.

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1781 days 3 hours and 38 minutes ago]

Fri, 28 May 2021 12:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/28/21 3:48 AM, jr wrote:
> >> ...
> >> What I've not done for arrays vs mixed arrays as yet is look for a
> >> method 'like' that employed to break out a few of the object types like
> >> light sources(1). The object flags popped into my head on Tor Olav's
> >> question.
> >
> > I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> > and so perhaps a complementary function (eg) 'is_type_details()' which returns
> > an array mixed, where the various flags are used to distinguish one ("390")
> > object from another.
> >
>
> Yes, is_type_details(), a possibility, but it would be work creeping
> well past "easy."
>
> Aside: For the details which could be provided as strings of text as to
> type, my thought was this work would be pushed onto users - or some
> include file maintainer - in the form of a macro containing a big switch
> kicking out text or setting up an array with, say, response strings:
> "The is type passed to MagicMacro24 is a light_source."

I was about to suggest (almost) the opposite.  :-)

thinking that if one (you :-)) were to set up an enum, covering the basics
(float, bool, vector, macro, function, array, string, such[*]), then changing
(in the parser, between versions) ids could be "contained" in one mapping.  then
'is_type()', and later perhaps its companion func, would always provide
consistent "numbers".  and yes, some include file to turn the numbers back into
human speak would be v useful (will collaborate if thought helpful).

[*] off the top of my head.  in most ("95%") situations, I think, just knowing
it's "an array", say, without the "fall out" from using 'dimensions(foo)' when
it isn't, will suffice.

> ...
> > (and the (snipped) macro examples too, while safe to use, would not allow me to
> > catch (as in handle with own error message) the eventual "odd" value, I think)
>
> You understood. What I coded up there is checking on the cheap; POV-Ray
> does it and the result is an internal parser error. What I had in mind
> for what I think you want to do - using id_type() - is something like
> the attached test case. Yes/No?

thanks.  will look at code tonight/tomorrow.

regards, jr.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1781 days 5 hours and 7 minutes ago]

Fri, 28 May 2021 11:00:34 GMT

On 5/28/21 3:48 AM, jr wrote:
> hi,
> 
...
>> ...
>>> supported by a similar function which returns an 'array mixed' with the various
>>> "properties"/categories broken out?
>>
>> What I've not done for arrays vs mixed arrays as yet is look for a
>> method 'like' that employed to break out a few of the object types like
>> light sources(1). The object flags popped into my head on Tor Olav's
>> question.
> 
> I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
> and so perhaps a complementary function (eg) 'is_type_details()' which returns
> an array mixed, where the various flags are used to distinguish one ("390")
> object from another.
> 

Yes, is_type_details(), a possibility, but it would be work creeping 
well past "easy."

Aside: For the details which could be provided as strings of text as to 
type, my thought was this work would be pushed onto users - or some 
include file maintainer - in the form of a macro containing a big switch 
kicking out text or setting up an array with, say, response strings: 
"The is type passed to MagicMacro24 is a light_source."

> 
>> Even without getting different type ids for arrays vs mixed arrays today
>> from id_type, you can walk a mixed array asking about the types for each
>> element and in that way via SDL looping (or your foreach work) build up
>> what types in total are seen for any given the mixed array.
> 
> not sure I really understand.  if some macro expects an array mixed parameter,
> say {3-vect, string, bool}, I do not know of a "safe" way to check all three.
> for instance, whether I use 'strlen(string)' or similar, if it's not a string,
> POV-Ray will "intervene".  (did I misread?)
> 
> (and the (snipped) macro examples too, while safe to use, would not allow me to
> catch (as in handle with own error message) the eventual "odd" value, I think)
> 

You understood. What I coded up there is checking on the cheap; POV-Ray 
does it and the result is an internal parser error. What I had in mind 
for what I think you want to do - using id_type() - is something like 
the attached test case. Yes/No?

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1781 days 8 hours and 18 minutes ago]

Fri, 28 May 2021 07:50:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/27/21 2:08 AM, jr wrote:
> > ...
> >> As implemented it's a stand alone bit of code.
> >
> > that is good.  (afaict)  so it could be issued as a patch to the 3.8.0-alpha?
>
> Could be. Yes.

nice.

> ...
> > supported by a similar function which returns an 'array mixed' with the various
> > "properties"/categories broken out?
>
> What I've not done for arrays vs mixed arrays as yet is look for a
> method 'like' that employed to break out a few of the object types like
> light sources(1). The object flags popped into my head on Tor Olav's
> question.

I put this badly.  meant that 'is_type()' probably "will do" for most use cases,
and so perhaps a complementary function (eg) 'is_type_details()' which returns
an array mixed, where the various flags are used to distinguish one ("390")
object from another.

> Even without getting different type ids for arrays vs mixed arrays today
> from id_type, you can walk a mixed array asking about the types for each
> element and in that way via SDL looping (or your foreach work) build up
> what types in total are seen for any given the mixed array.

not sure I really understand.  if some macro expects an array mixed parameter,
say {3-vect, string, bool}, I do not know of a "safe" way to check all three.
for instance, whether I use 'strlen(string)' or similar, if it's not a string,
POV-Ray will "intervene".  (did I misread?)

(and the (snipped) macro examples too, while safe to use, would not allow me to
catch (as in handle with own error message) the eventual "odd" value, I think)

regards, jr.

[clipka] Re: Sniffing UberPOV [1781 days 22 hours and 49 minutes ago]

Thu, 27 May 2021 17:18:21 GMT

Am 05.03.2021 um 16:54 schrieb Cousin Ricky:
> Does anyone know whether it is possible for a scene file to detect 
> whether or not it is being rendered by UberPOV, without bombing out if 
> it is rendered by official POV-Ray?
> 
> Why would I need to do this?Â  Because I'm writing a macro that needs to 
> know whether or not true inverse square light attenuation is available. 
> For official POV-Ray, this is version >= 3.8, but for UberPOV, it is 
> version >= 3.71.
> 
> My first (and so far only) idea was to start with a test for the 
> existence of the variable 'unofficial', but it turns out POV-Ray 3.8 
> does the same test--but treats it as if it were a keyword.Â  This screws 
> up the test for any SDL code running under 3.8.


Some background information:

The problem arises with recent development versions of POV-Ray that (1) 
recognize `unofficial` as a proper keyword (as in `#version unofficial 
FOO`, which official POV-Ray has been supporting for ages in the sense 
that it prompts a very specific error message), and (2) report all 
recognized keywords as "defined" with respect to the `#ifdef` statement 
and its kin.

In v3.7 and early development versions identifying as v3.7.1, the 
statement had been handled in a comparatively hackish manner, which did 
not recognize `unofficial` as a proper keyword. Therefore, those 
versions are unproblematic.

In later v3.7.1 development versions, starting with 
v3.7.1-alpha.8449793, `unofficial` was promoted to a keyword proper. 
However, `#ifdef` and its kin still reported keywords as "not defined", 
so those versions are also unproblematic.

The problem was only introduced with the experimental 
v3.8.0-tokenizer.9841908, and later with the mainline 
v3.8.0-alpha.10008988, which changed the behaviour of `#ifdef` to report 
keywords as "defined", including the `unofficial` keyword.

Note however that the change of the `#ifdef` statement also means that 
support for the `patch` keyword can be tested directly, in a manner that 
is also compatible with older versions. Also, whether or not `#ifdef` 
works this way can be tested with a known keyword.


The following code will cause parse warnings with some versions, but 
other than that it should work fine for any version:

---------------------------------------------------------------
// Tell POV-Ray that we'll be doing our own feature probing.
#version version;

// Test whether UberPOV-style `#patch`/`patch()` mechanism
// seems to be available
#ifdef(ifdef)
   // New `#ifdef` behaviour, reporting supported keywords as defined.
   // We can probe for support of the `patch` keyword directly.
   #declare HAVE_PATCH = defined(patch);
#else
   // Old `#ifdef` behaviour, reporting keywords as undefined.
   // We can probe for support of the `unofficial` variable.
   #ifdef(unofficial)
     #declare HAVE_PATCH = (unofficial = "patch");
   #else
     #declare HAVE_PATCH = false;
   #end
#end

// Probe for required features
#if(HAVE_PATCH)
   // Probe features individually via `#patch`/`patch()`
   // (or probe for UberPOV version via that same mechanism
   // using "upov" as the feature name, though this is somewhat
   // discouraged)
   ...
#else
   // Probe via `#version`/`versionÂ´
   ...
#end
---------------------------------------------------------------


Note that support for the `patch` keyword per se does _not_ necessarily 
imply that the version used is actually UberPOV. Most notably, the 
details of the mechanism were specifically designed such that other 
derivatives of POV-Ray could use the same mechanism without conflict, 
and official POV-Ray might also eventually support it, if only to 
further promote it as a standard mechanism for detecting derivatives and 
probing for their features.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1782 days 6 hours and 18 minutes ago]

Thu, 27 May 2021 09:50:17 GMT

On 5/27/21 2:08 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 5/25/21 8:40 AM, jr wrote:
>>> could it be implemented as-easily in POV-Ray
>>> too?
>>
>> You, and that concept of easy... ;-)
> 
> my ignorance wrt POV-Ray source stands me in good stead..  :-)

:-) Me alongside. Nobody understands the whole of the code base.

> 
> 
>> As implemented it's a stand alone bit of code.
> 
> that is good.  (afaict)  so it could be issued as a patch to the 3.8.0-alpha?
> 

Could be. Yes.

> 
>> Aside: I did manage to use some of the object flags to break out
>> light_sources, csg (merge,union,difference,intersection), light unions
>> and light groups from the object id category. The id sub-catagories Left
>> in as probably more useful than not, but there is the nagging thought it
>> might somewhere be the wrong thing to do.
> 
> forgot to thank you for the vector id background info.  read in conjunction with
> the above, I'm thinking a two function approach perhaps, 'id_type' much as is,
> supported by a similar function which returns an 'array mixed' with the various
> "properties"/categories broken out?
> 

What I've not done for arrays vs mixed arrays as yet is look for a 
method 'like' that employed to break out a few of the object types like 
light sources(1). The object flags popped into my head on Tor Olav's 
question.

Even without getting different type ids for arrays vs mixed arrays today 
from id_type, you can walk a mixed array asking about the types for each 
element and in that way via SDL looping (or your foreach work) build up 
what types in total are seen for any given the mixed array.

(1) - Strictly, the information isn't needed for code safety sake. We 
can today (v3.8) employ the back door type checking I mentioned 
'somewhere' to be sure types coming in via mixed arrays are consistent - 
when then need to be. I used the technique while adopting Tor Olav's 
array statics macro suggestions. Let me see, as two examples, I used the 
trick with his Mean and Minimum macros which now look like:

#macro Mean(Values)

     #local N = dimension_size(Values, 1);
     #local Sum = array[1] // Fixed array types cannot change.
     #local Sum[0] = Values[0];
     #for (I, 1, N - 1)
         #local Sum[0] = Sum[0] + Values[I];
     #end // for

     (Sum[0]/N)

#end // macro Mean

#macro Minimum(Values)

     #local N = dimension_size(Values, 1);
     #local Min = array[2] {1,1} // Fixed array types cannot change.
     #local Min[0] = Values[0];  // Better err msg - min() floats only.
     #for (I, 1, N - 1)
         #local Min[1] = Values[I]; // Better err msg.
         #local Min[0] = min(Min[0], Min[1]);
     #end // for

     Min[0]

#end // macro Minimu

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1782 days 9 hours and 58 minutes ago]

Thu, 27 May 2021 06:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/25/21 8:40 AM, jr wrote:
> > could it be implemented as-easily in POV-Ray
> > too?
>
> You, and that concept of easy... ;-)

my ignorance wrt POV-Ray source stands me in good stead..  :-)

> As implemented it's a stand alone bit of code.

that is good.  (afaict)  so it could be issued as a patch to the 3.8.0-alpha?

> Aside: I did manage to use some of the object flags to break out
> light_sources, csg (merge,union,difference,intersection), light unions
> and light groups from the object id category. The id sub-catagories Left
> in as probably more useful than not, but there is the nagging thought it
> might somewhere be the wrong thing to do.

forgot to thank you for the vector id background info.  read in conjunction with
the above, I'm thinking a two function approach perhaps, 'id_type' much as is,
supported by a similar function which returns an 'array mixed' with the various
"properties"/categories broken out?

regards, jr.

[clipka] Re: Sniffing UberPOV [1782 days 15 hours and 51 minutes ago]

Thu, 27 May 2021 00:17:08 GMT

Am 08.03.2021 um 19:30 schrieb Cousin Ricky:

> Exactly.Â  The results are the same in official POV-Ray 3.8.Â 
The problem 
> is that the test on 'unofficial' is reliable _only_ with a patch that 
> uses it--which is exactly what we don't know in advance; and any further 
> refined tests are pointless.

Consider this a bug in the POV-Ray v3.8 betas.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1783 days 5 hours and 21 minutes ago]

Wed, 26 May 2021 10:47:00 GMT

On 5/25/21 8:40 AM, jr wrote:
> could it be implemented as-easily in POV-Ray
> too?

You, and that concept of easy... ;-) As implemented it's a stand alone 
bit of code.

Aside: I did manage to use some of the object flags to break out 
light_sources, csg (merge,union,difference,intersection), light unions 
and light groups from the object id category. The id sub-catagories Left 
in as probably more useful than not, but there is the nagging thought it 
might somewhere be the wrong thing to do.

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1784 days 3 hours and 23 minutes ago]

Tue, 25 May 2021 12:45:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I found a solution using the new to v3.8 global dictionary. You have to
> code macros with the 'global.' prefix...
>
> Supposing I have a macro wrapping id_type():
>
> #macro Mcr_id_type(_id)
>      id_type(_id)
> #end
>
> so I can create IDs on the fly as in:
>
> #debug concat("float id = ",str(Mcr_id_type(1.2*(1/3)),4,1),"\n")
>
> I can then grab the Mcr_id_type macro's id type number with:
>
> #debug concat("macro = ",str(id_type(global.Mcr_id_type),4,1),"\n")

neat.  (lucky there's a non-"messy" way :-))  question: does 'id_type()' rely on
any 'povr' branch only features, or could it be implemented as-easily in POV-Ray
too?  (and if yes, when??  :-))


regards, jr.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1784 days 5 hours and 37 minutes ago]

Tue, 25 May 2021 10:30:37 GMT

On 5/25/21 4:40 AM, jr wrote:
> this looks v promising.  am  a little confused by the sample output posted,
> expected, for example, the four vector types to have (somewhat) related ids.
> 

This is partly because internally the vector types are:

UV_ID_TOKEN, VECTOR_ID_TOKEN, VECTOR_4D_ID_TOKEN and COLOUR_ID_TOKEN.

The token enums are also sometimes also ordered into sections - 
internally called catagories. The VECTOR_ID_TOKEN is in a vector 
category grouping while the others are not for other reasons of parsing 
code I guess. The COLOUR_ID_TOKEN is exempt from the color category too(1).

I think it's because there is, for example, color/colour keywords and so 
to color IDs. I don't think there is a 'vector' keyword, so vector ids 
can be lumped with other generic vector stuff like vcross.

I'm not completely sure of all of it, there isn't a uv keyword, but 
maybe because we have uv_vectors? I don't know.

>> ...
>> In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to
>> evaluate macro names because once they exist the parser attempts to run
>> them. I don't see a way to work around it - excepting maybe via some
>> very messy methods.
...
> testing via 'defined(macroname)'?  (not tried it with macroname as string, but
> maybe Parse_String could help then).

I found a solution using the new to v3.8 global dictionary. You have to 
code macros with the 'global.' prefix...

Supposing I have a macro wrapping id_type():

#macro Mcr_id_type(_id)
     id_type(_id)
#end

so I can create IDs on the fly as in:

#debug concat("float id = ",str(Mcr_id_type(1.2*(1/3)),4,1),"\n")

I can then grab the Mcr_id_type macro's id type number with:

#debug concat("macro = ",str(id_type(global.Mcr_id_type),4,1),"\n")

Bill P.

[jr] Re: Initial povr branch keywords id_type() and i... [1784 days 7 hours and 23 minutes ago]

Tue, 25 May 2021 08:45:00 GMT

hi,

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

this looks v promising.  am  a little confused by the sample output posted,
expected, for example, the four vector types to have (somewhat) related ids.

> ...
> In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to
> evaluate macro names because once they exist the parser attempts to run
> them. I don't see a way to work around it - excepting maybe via some
> very messy methods.

testing via 'defined(macroname)'?  (not tried it with macroname as string, but
maybe Parse_String could help then).

regards, jr.

[William F Pokorny] Re: Initial povr branch keywords id_type() and i... [1784 days 12 hours and 45 minutes ago]

Tue, 25 May 2021 03:22:40 GMT

On 5/24/21 2:17 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> In povray.general we recently discussed implementing some limited type
>> checking. Attached is an include files showing testing for two new
>> keywords in the povr branch called id_type() and id_types_match().
>>
>> Note. Though the id values often change from release to release I found
>> an id_type() works in a switch statement making the id_type() worthwhile
>> too, I thought.
> 
...
> Can it also be used with different functions types, splines, matrices,
> transforms, materials, file descriptors, light sources, cameras, color maps, and
> other maps ?
> 

Played with these more tonight and I'm now leaning toward dropping 
id_types_match(). As with most things the more I played the more the 
hidden gotchas popped out, and the more complex the code got.

Answers to your category/type questions are mostly yes. Functions come 
in two types depending on whether they return doubles or vectors. Light 
sources I've not tested as yet, but I think those have always been 
considered objects and so will likely get lumped with spheres et al(1).

In some oddness, there is a MACRO_ID_TOKEN, but it's impossible to 
evaluate macro names because once they exist the parser attempts to run 
them. I don't see a way to work around it - excepting maybe via some 
very messy methods.

Bill P.

(1) - It's only code, as an old friend used to say to my enhancement 
requests. :-) Likely some way to tell the object is really a light and 
we could then set some bogus, large value maybe - or negative values. 
There are, I know, some object type 'flags' that get set when objects 
are created. We'll see.

[Tor Olav Kristensen] Re: Initial povr branch keywords id_type() and i... [1784 days 21 hours and 48 minutes ago]

Mon, 24 May 2021 18:20:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> In povray.general we recently discussed implementing some limited type
> checking. Attached is an include files showing testing for two new
> keywords in the povr branch called id_type() and id_types_match().
>
> Note. Though the id values often change from release to release I found
> an id_type() works in a switch statement making the id_type() worthwhile
> too, I thought.

Nice !

Can it also be used with different functions types, splines, matrices,
transforms, materials, file descriptors, light sources, cameras, color maps, and
other maps ?

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

[ingo] Re: Initial povr branch keywords id_type() and i... [1784 days 23 hours and 1 minute ago]

Mon, 24 May 2021 17:06:49 GMT

in news:60abd77d$1@news.povray.org William F Pokorny wrote:

> id_type() and id_types_match()

Very useful. Thanks,

Ingo

[William F Pokorny] Initial povr branch keywords id_type() and id_ty... [1784 days 23 hours and 25 minutes ago]

Mon, 24 May 2021 16:42:37 GMT

In povray.general we recently discussed implementing some limited type 
checking. Attached is an include files showing testing for two new 
keywords in the povr branch called id_type() and id_types_match().

Note. Though the id values often change from release to release I found 
an id_type() works in a switch statement making the id_type() worthwhile 
too, I thought.

//---
#include "id_types.inc"

Mcr_ID_type(ID_type_float)
Mcr_ID_type(ID_type_string)
Mcr_ID_type("Hello")

Mcr_ID_type_test()

#error "\nTesting. Stop early\n"
//---

An excerpt of the output follows showing the current povr values for 
certain types. Notably the parser treats some things we might think of 
as separate as the same internal ID.
---
float       = 27.0
string      = 527.0
vector2D    = 584.0
vector3D    = 71.0
vector4D    = 592.0
vector5D    = 95.0
dictionary  = 209.0
array       = 121.0
array_mixed = 121.0
sphere      = 390.0
box         = 390.0
object      = 390.0
merge       = 390.0
union       = 390.0
color       = 95.0
finish      = 247.0
normal      = 381.0
pigment     = 420.0
texture     = 542.0
---

Bill P.

[Bald Eagle] Re: On the long unfinished normal related warps ... [1790 days 15 hours and 8 minutes ago]

Wed, 19 May 2021 01:00:00 GMT

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

> --- but
> What you should be able to do - since you can define pigments and
> normals independently ahead of inclusion in a texture for each
> shape/surface - is use different maps for the pigment and normal
> uv_mapping for 'each' low level uv map-able thingy. Pigments, normals or
> both could use maps created for the object as they need to be when
> placed in global space. No automation for this as far as I know - you'd
> have to work out how to create the thingy by thingy map(s) cut from
> global space on your own.

So, I could define a function that translated an <x, y, z> coordinate (that is
used internally to calculate a uv coordinate) to a projected <x, y, z>
coordinate that is outside the range of the 0-1 uv vectors of the local space...

<insert headache here>

Then do normal {function {f_translate (x, y, x)}, which should should remap the
local <x, y, z> mapping of the uv vectors to a projected set of uv vectors that
in turn correspond to the actual spatial positions of the bezier patch...

Egads.

I'm a _little_ surprised that no one has ever brought this up before, but then
again, I'm always going off into the weeds when doing what seem to be perfectly
ordinary things...

I'm wondering if you were to implement this in povr source, if it would be as
simple as defining a "no_uv" normal type that simply uses the native EPoint
instead of the uv_vector coordinate.

I will have think a bit more on this and see when I can puzzle out something
functional [sic].

Thanks for the analysis and ideas for a solution   :)

[William F Pokorny] Re: On the long unfinished normal related warps ... [1790 days 21 hours and 11 minutes ago]

Tue, 18 May 2021 18:56:24 GMT

On 5/18/21 1:34 PM, Bald Eagle wrote:
> What I'm asking about is the separability of the texture and the normal.
> 
> Can I have a distinct uv-mapped texture for each object (which is bounded /
> defined by the uv vectors), but have them all share a "regular" normal that
> extends throughout all of POV-space and is calculated based on the POV-space
> <x,y,z> location vector?
> 
> So: can I apply a POV-space normal to an object but then also apply the local
> shape intersection point uv-mapped texture.  Or some other way of accomplishing
> the same end result.

OK. Thanks. I believe I better understand your question.

With the repeated disclaimer I'm not a regular uv map user, I think the 
answer is no, but...

---
The reason is uv mapping works with primitives(1). It's a mechanism 
which associates the ray intersection on the surface of that primitive 
with a 2d map position. This mapping comes from the primitive 
shape/surface code and is the same for pigments and normals.

(1) You can use the uv_mapping keyword for csg entities, but I believe 
it simply does a default (planar?) map. Somewhere in recent years there 
are posts related to someone trying this.

Because uv mapping works at the primitive level you must define a 
texture's pigment and normal mapping at the base shape/surface - and 
once (a) texture(s) are defined for the surfaces of something - they are 
set - even if the object is included in later CSG. You cannot change 
them or add to them.

--- but
What you should be able to do - since you can define pigments and 
normals independently ahead of inclusion in a texture for each 
shape/surface - is use different maps for the pigment and normal 
uv_mapping for 'each' low level uv map-able thingy. Pigments, normals or 
both could use maps created for the object as they need to be when 
placed in global space. No automation for this as far as I know - you'd 
have to work out how to create the thingy by thingy map(s) cut from 
global space on your own.

All as far as know - maybe I've got something wrong, or someone has done 
something clever(2).

Bill P.

(2) - A very rough idea would be to do something with _map values based 
on passing global space values to a function, but I don't see all of how 
it would work at the moment - and the _map would either be huge to 
encompass all the global positions or limited. Another idea might be to 
make use of povr like normal chaining within average maps, but I have no 
idea, if, or how uv mapped normals might work/act within a normal { 
average ... } alongside other types of normals. Never tried to mix uv 
mapped types with others for pigments or normals.

[Bald Eagle] Re: On the long unfinished normal related warps ... [1790 days 22 hours and 33 minutes ago]

Tue, 18 May 2021 17:35:00 GMT

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

> If I understand your question, yes, in that you are not using a warped
> EPoint when uv mapping. The 'EPoint' is the local shape intersection
> point.

OK

> > And with regard to applying a global normal pattern that is
> > dependent upon an object's location in POV-space, is this desirable, expected,
> > and can it be overridden?
> >
>
> Again not quite sure I follow. You can delay defining all shape's
> textures until you are at the global scene level. Say a set of 50
> spheres in a union where the (not uv mapped) texture including the
> normal is defined at the union definition or later. There the position
> of the 50 spheres within the texture eventually applied will result in
> differences sphere to sphere.

What I'm asking about is the separability of the texture and the normal.

Can I have a distinct uv-mapped texture for each object (which is bounded /
defined by the uv vectors), but have them all share a "regular" normal that
extends throughout all of POV-space and is calculated based on the POV-space
<x,y,z> location vector?

So: can I apply a POV-space normal to an object but then also apply the local
shape intersection point uv-mapped texture.  Or some other way of accomplishing
the same end result.

[William F Pokorny] Re: On the long unfinished normal related warps ... [1791 days 5 hours and 15 minutes ago]

Tue, 18 May 2021 10:53:08 GMT

On 5/17/21 2:26 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
>> So, I started to play with an idea for new normal pattern which
>> allows/enables this. It's currently working with the difference between
>> the intersection location and the warp{} / turbulence affected EPoint.
>> In other words, there isn't an actual specific perturbation method /
>> pattern - it's whatever your warp{}s create.
> 
> So it would be much like doing normal {null warp repeat x turbulence 0.3}
> where "null" is just sort of like an identity matrix - no change.
> 

(1) - I forgot to add the planned footnote in my original post. :-) Was 
just some ramble about options and complications.

Yes, that's a good way to think about it. Might even add 'null" as the 
normal pattern name in the end(2) - it's currently the default option in 
the normal bevy "collection."

(2) - I'm playing with two actual methods. "null type n" - don't know.

...
> That second one seems like it has real potential.  Given that one of the mothods
> for arranging things "evenly" on the surface of a sphere is using a spiral /
> loxodrome, then accomplishing a very close approximation to that using only a
> simple normal statement would be a really powerful and welcome development.

Yes, I've been thinking some about geodesic centered - normal direction 
sets where the incoming normal would be matched to closest direction 
match creating a frame for normal perturbations. As you suggest, others 
possible.

I need at some point to go back and work more on the black hole 
'spherically contained' warps. Perhaps adding cylindrical black holes, 
etc, with an ability to orient to an arbitrary direction vector. With 
warps too there is more possible.

> This reminds me of my unsolved problem applying normals to bezier patches:
> 
> http://news.povray.org/web.5f6a91889d9b31d91f9dae300%40news.povray.org
> regarding
>
https://news.povray.org/povray.binaries.images/message/%3Cweb.5f45adba5d69181b1f9dae300%40news.povray.org%3E/#%3Cweb.5f
> 45adba5d69181b1f9dae300%40news.povray.org%3E
> 
> Do you have any inkling if the uv-mapping coordinates affect the application of
> the normal pattern, and where in the code that factors in?  Because I see that
> as being another thing that's hiding in there that we might not be fully aware
> of.

I've not spent any time looking at it, but there is a normal block uv 
mapping in normal.cpp. I don't use uv mapping much, but when active it 
should map the intersection location on the uv map-able shape/object to 
the appropriate 2d uv map position in the normal pattern in the 0-1, xy 
square in the z=0 plane. Said another way, when uv mapping normals you 
are explicitly setting the perturbed normal for the 3d surface 
intersection from a 2d map. This is the normal pattern method if uv 
mapping used for the normal block of the texture.

A point on your first link, given the questions asked there. There is 
only one normal per material/texture for an object. That normal can 
itself be and average, normal list or normal map of other normals, but 
it's one normal as included in the texture. When you add a normal block 
after an existing texture on an object as follows:

sphere { ... texture { T_wNormal } normal { granite } }

The normal in the sphere's texture is now 'normal { granite }' with 
everything else the same; the normal originally in the texture 
T_wNormal is gone for this sphere's texture.

> So I guess maybe what I'm asking is, do the uv-mapping vectors override the
> global POV-space location vectors, in essence (locally/temporarily) redefining
> the EPoint?  

If I understand your question, yes, in that you are not using a warped 
EPoint when uv mapping. The 'EPoint' is the local shape intersection 
point.

> And with regard to applying a global normal pattern that is
> dependent upon an object's location in POV-space, is this desirable, expected,
> and can it be overridden?
> 

Again not quite sure I follow. You can delay defining all shape's 
textures until you are at the global scene level. Say a set of 50 
spheres in a union where the (not uv mapped) texture including the 
normal is defined at the union definition or later. There the position 
of the 50 spheres within the texture eventually applied will result in 
differences sphere to sphere.

Bill P.

[Bald Eagle] Re: On the long unfinished normal related warps ... [1791 days 21 hours and 38 minutes ago]

Mon, 17 May 2021 18:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> The warp.cpp source code has long had some unfinished normal related
> warp and unwarp hooks. Those of us working on the code of late haven't
> really understood them - as far as I know.

So, when I was coding some C++ stuff, I had to puzzle out passing things by
pointer, reference, or value.  Some of the code in the section we're talking
about I can read just fine - the stuff with the "->", notsomuch.

> While working of late on normal block patterns it hit me we don't warp
> the incoming normal, but rather the perturbation patterns/methods via
> the unwarped / warped EPoint(1). We cannot today warp the incoming raw
> normals with warp{}s.

I have read that 4 or 5 times, and I think I understand it and agree.  :)

> So, I started to play with an idea for new normal pattern which
> allows/enables this. It's currently working with the difference between
> the intersection location and the warp{} / turbulence affected EPoint.
> In other words, there isn't an actual specific perturbation method /
> pattern - it's whatever your warp{}s create.

So it would be much like doing normal {null warp repeat x turbulence 0.3}
where "null" is just sort of like an identity matrix - no change.

>
> Attached are a couple of images. One uses three repeat warps and a touch
> of turbulence. The second a spiral -> turbulence -> spiral combination.

That second one seems like it has real potential.  Given that one of the mothods
for arranging things "evenly" on the surface of a sphere is using a spiral /
loxodrome, then accomplishing a very close approximation to that using only a
simple normal statement would be a really powerful and welcome development.

This reminds me of my unsolved problem applying normals to bezier patches:

http://news.povray.org/web.5f6a91889d9b31d91f9dae300%40news.povray.org
regarding
https://news.povray.org/povray.binaries.images/message/%3Cweb.5f45adba5d69181b1f9dae300%40news.povray.org%3E/#%3Cweb.5f
45adba5d69181b1f9dae300%40news.povray.org%3E

Do you have any inkling if the uv-mapping coordinates affect the application of
the normal pattern, and where in the code that factors in?  Because I see that
as being another thing that's hiding in there that we might not be fully aware
of.
So I guess maybe what I'm asking is, do the uv-mapping vectors override the
global POV-space location vectors, in essence (locally/temporarily) redefining
the EPoint?  And with regard to applying a global normal pattern that is
dependent upon an object's location in POV-space, is this desirable, expected,
and can it be overridden?

[William F Pokorny] On the long unfinished normal related warps in w... [1792 days 3 hours and 8 minutes ago]

Mon, 17 May 2021 13:00:10 GMT

The warp.cpp source code has long had some unfinished normal related 
warp and unwarp hooks. Those of us working on the code of late haven't 
really understood them - as far as I know.

Patterns today work in the normal block with all sorts of transforms and 
warps, so those hooks are aimed at...?

While working of late on normal block patterns it hit me we don't warp 
the incoming normal, but rather the perturbation patterns/methods via 
the unwarped / warped EPoint(1). We cannot today warp the incoming raw 
normals with warp{}s.

So, I started to play with an idea for new normal pattern which 
allows/enables this. It's currently working with the difference between 
the intersection location and the warp{} / turbulence affected EPoint. 
In other words, there isn't an actual specific perturbation method / 
pattern - it's whatever your warp{}s create.

Attached are a couple of images. One uses three repeat warps and a touch 
of turbulence. The second a spiral -> turbulence -> spiral combination.

Still playing / thinking, but looks promising.

Bill P.

[William F Pokorny] Re: New f_vangle inbuilt with povr branch. [1795 days 4 hours and 52 minutes ago]

Fri, 14 May 2021 11:15:24 GMT

On 5/14/21 6:39 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> - Michael Andrews published a convhull.in which uses it.
> 
> I would like to take a look at that - can't seem to find where it was published.
> 

---
There was a povray.binaries.images thread:

http://news.povray.org/povray.binaries.images/thread/%3C3e459994%40news.povray.org%3E

Web Message 3e459994@news.povray.org


---
Looks like maybe the files came from:

http://news.povray.org/povray.binaries.scene-files/thread/%3C3e459b0a%40news.povray.org%3E/

Web Message: web.44cabb94759cbd10546ee4f70@news.povray.org

but the file links look messed up there. Let me see if I can still post 
to that thread from Thunderbird. Nope. Apparently fell off the end...

I'll post a tarball of the files also to povray.binaries.scene-files to 
be consistent.

Bill P.

[Bald Eagle] Re: New f_vangle inbuilt with povr branch. [1795 days 5 hours and 28 minutes ago]

Fri, 14 May 2021 10:40:00 GMT

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

> - Michael Andrews published a convhull.in which uses it.

I would like to take a look at that - can't seem to find where it was published.

Thanks  :)

[William F Pokorny] Re: New f_vangle inbuilt with povr branch. [1795 days 5 hours and 43 minutes ago]

Fri, 14 May 2021 10:24:21 GMT

On 5/14/21 4:50 AM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Method 0. By targeted random vector experimentation the traditional
>> method provides for 7 digits of accuracy on when very near a zero angle
>> or very near pi. In practice, with vectors not near coincident, or near
>> exactly opposing the accuracy is much better.
>>
>> Method 1. By targeted random vector experimentation the traditional
>> method provides for 12 significant digits of accuracy near 0.0 or pi in
>> angle. It often provides a few more digits.
>> ...
> 
> Method 1:
> You mention the traditional method also here. Did you mean the new method ?
> 

Ah, thank you! Extra points for letting me know ahead of the commit of 
my mistake. :-)

Bill P.

[William F Pokorny] Re: New f_vangle inbuilt with povr branch. [1795 days 5 hours and 45 minutes ago]

Fri, 14 May 2021 10:22:24 GMT

On 5/13/21 11:24 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> Nice work Bill!
> 

Thanks. Today I'll be working through several git commits including this 
work.

> It's good to be able to choose which formula to use for the angle calculation.
> 
> But I'm struggling to see the usefulness of the VRotation() and VRotation()
> macros. I can not remember that I ever had the need to do the exact calculations
> they do. And if one understand the intricate explanation for how to use them,
> one is likely to do fine without them. Also there's to much work preparing for
> them.
> 
> Perhaps someone can post code for a case where one of them is really useful ?

VRotation is used in Rune S. Johansen's Spline_Trans from 
transforms.inc. I see that as the immediately significant one.

---
Searching through my archives turned up a couple more.

- Tim Atwood put out a spline_tools.inc - which looks quite similar to 
Rune's code.

- Michael Andrews published a convhull.in which uses it.

All make use of VProject_Plane for the arguments. As to whether the 
VRotation use was strictly needed...

I didn't turn up any use of VRotationD.

Bill P.

[Tor Olav Kristensen] Re: New f_vangle inbuilt with povr branch. [1795 days 7 hours and 13 minutes ago]

Fri, 14 May 2021 08:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>...
> Method 0. By targeted random vector experimentation the traditional
> method provides for 7 digits of accuracy on when very near a zero angle
> or very near pi. In practice, with vectors not near coincident, or near
> exactly opposing the accuracy is much better.
>
> Method 1. By targeted random vector experimentation the traditional
> method provides for 12 significant digits of accuracy near 0.0 or pi in
> angle. It often provides a few more digits.
>...

Method 1:
You mention the traditional method also here. Did you mean the new method ?

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

[Tor Olav Kristensen] Re: New f_vangle inbuilt with povr branch. [1795 days 12 hours and 43 minutes ago]

Fri, 14 May 2021 03:25:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Ref:
>
> http://news.povray.org/povray.general/thread/%3C609d7f7f%241%40news.povray.org%3E/
>
> Web Message: 609a4569$1@news.povray.org
>
> As part of the effort referenced, added a new inbuilt functions called
> f_vangle(). A first pass of the help text follows.
>
> ---
> Returns angle of rotation between two vectors. Function mimics the
> traditional VAngle macro shipped with POV-Ray in two ways.  The angle is
> returned in radians. Wrap with degree() for answer in degrees.
>
> The first an implementation of the acos of the dot product - with -1 to
> 1 clamping of the dot product - which is the traditional one.
>
> Tor Olav Kristensen suggested a more accurate method to the povray
> general news group on May 06, 2021 which is the second method.   In
> isolation it's obviously slower - sometimes significantly so - (30-40%)
> over the traditional acos based method. However, in the blur of branch
> predictions supporting both methods and modern CPU speculative execution
> the form as implemented herein is often the fastest. When slower it's
> not that much slower in the context of typical parser time use.
>
> In targeted random vector experimentation the dot product was found to
> return max and min values of +1.00000000000000067 and
> -1.00000000000000067, respectively.  Meaning with the traditional method
> the -1..1 clipping is absolutely necessary to avoid acos domain errors.
>
> Method 0. By targeted random vector experimentation the traditional
> method provides for 7 digits of accuracy on when very near a zero angle
> or very near pi. In practice, with vectors not near coincident, or near
> exactly opposing the accuracy is much better.
>
> Method 1. By targeted random vector experimentation the traditional
> method provides for 12 significant digits of accuracy near 0.0 or pi in
> angle. It often provides a few more digits.
>
> The largest differences seen between the two methods, over tens of
> millions of random vector pairs, was always less than 1e-7.
>
> Using this inbuilt function directly is up to 2.5 times faster no matter
> the mode than using the macro VAngle. The macro may be more convenient
> in that vectors can be passed directly.
>
> Parameters:
>
> 1. First vector x value.
>
> 2. First vector y value.
>
> 3. First vector z value.
>
> 4. Second vector x value.
>
> 5. Second vector y value.
>
> 6. Second vector z value.
>
> 7. Method to use. If 0.0, the traditional acos(dot(v1,v2)) method is
> used. If 1.0, Tor Olav's suggested method is used.
>
> ---
> In math.inc now have:
>
> #macro VAngle(V1, V2) f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1) #end
>
> #macro VAngleD(V1, V2)
>    degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
> #end
>
> #macro VRotation(V1, V2, Axis)
>     (f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1)
>     *(vdot(Axis,vcross(V1,V2))<0?-1:1))
> #end
>
> #macro VRotationD(V1, V2, Axis)
>     (degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
>     *(vdot(Axis,vcross(V1,V2))<0?-1:1))
> #end


Nice work Bill!

It's good to be able to choose which formula to use for the angle calculation.

But I'm struggling to see the usefulness of the VRotation() and VRotation()
macros. I can not remember that I ever had the need to do the exact calculations
they do. And if one understand the intricate explanation for how to use them,
one is likely to do fine without them. Also there's to much work preparing for
them.

Perhaps someone can post code for a case where one of them is really useful ?

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

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. b0bc... [1795 days 19 hours and 47 minutes ago]

Thu, 13 May 2021 20:20:30 GMT

On 5/13/21 11:43 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> You seem to solve so many issues in that linux only branch, is there a chance
> that some of those fix propagate to master or do they already? 

They don't get into v3.8 master today as it is not being updated for a 
couple years. Where I believe fixes could be adopted more or less 
directly by the v3.8 master branch, I make a point to publish them on 
this news server or sometimes on github.

If mainstream work resumes, I have some hope the investigative 
information on issues will be of help, if not always my code changes.

> Sorry if this is
> not what you were referring to at all, but some unjustified overhead to the use
> of separated pov macro files was mentioned numerous times by Clipka and
> supposedly solved in his branch, just in case.
> 

I believe the v3.8 master branch, as it sits, has all Christoph's 
completed macro performance enhancements. So my branch, hgpovray38 and 
qtpovray have them too being based on that code - unless I've missed 
something.

Bill P.

[William F Pokorny] New f_vangle inbuilt with povr branch. [1795 days 19 hours and 58 minutes ago]

Thu, 13 May 2021 20:09:35 GMT

Ref:

http://news.povray.org/povray.general/thread/%3C609d7f7f%241%40news.povray.org%3E/

Web Message: 609a4569$1@news.povray.org

As part of the effort referenced, added a new inbuilt functions called 
f_vangle(). A first pass of the help text follows.

---
Returns angle of rotation between two vectors. Function mimics the 
traditional VAngle macro shipped with POV-Ray in two ways.  The angle is 
returned in radians. Wrap with degree() for answer in degrees.

The first an implementation of the acos of the dot product - with -1 to 
1 clamping of the dot product - which is the traditional one.

Tor Olav Kristensen suggested a more accurate method to the povray 
general news group on May 06, 2021 which is the second method.   In 
isolation it's obviously slower - sometimes significantly so - (30-40%) 
over the traditional acos based method. However, in the blur of branch 
predictions supporting both methods and modern CPU speculative execution 
the form as implemented herein is often the fastest. When slower it's 
not that much slower in the context of typical parser time use.

In targeted random vector experimentation the dot product was found to 
return max and min values of +1.00000000000000067 and 
-1.00000000000000067, respectively.  Meaning with the traditional method 
the -1..1 clipping is absolutely necessary to avoid acos domain errors.

Method 0. By targeted random vector experimentation the traditional 
method provides for 7 digits of accuracy on when very near a zero angle 
or very near pi. In practice, with vectors not near coincident, or near 
exactly opposing the accuracy is much better.

Method 1. By targeted random vector experimentation the traditional 
method provides for 12 significant digits of accuracy near 0.0 or pi in 
angle. It often provides a few more digits.

The largest differences seen between the two methods, over tens of 
millions of random vector pairs, was always less than 1e-7.

Using this inbuilt function directly is up to 2.5 times faster no matter 
the mode than using the macro VAngle. The macro may be more convenient 
in that vectors can be passed directly.

Parameters:

1. First vector x value.

2. First vector y value.

3. First vector z value.

4. Second vector x value.

5. Second vector y value.

6. Second vector z value.

7. Method to use. If 0.0, the traditional acos(dot(v1,v2)) method is 
used. If 1.0, Tor Olav's suggested method is used.

---
In math.inc now have:

#macro VAngle(V1, V2) f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1) #end

#macro VAngleD(V1, V2)
   degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
#end

#macro VRotation(V1, V2, Axis)
    (f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1)
    *(vdot(Axis,vcross(V1,V2))<0?-1:1))
#end

#macro VRotationD(V1, V2, Axis)
    (degrees(f_vangle(V1.x,V1.y,V1.z,V2.x,V2.y,V2.z,1))
    *(vdot(Axis,vcross(V1,V2))<0?-1:1))
#end

Bill P.

[Mr] Re: An updated povr tarball for Unix/Linux. b0bc... [1796 days and 23 minutes ago]

Thu, 13 May 2021 15:45:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/26/21 7:42 AM, William F Pokorny wrote:
> > Ref:
> >
> >
http://news.povray.org/povray.binaries.programming/message/%3C6086a32c%40news.povray.org%3E/#%3C6086a32c%40news.pov
ray.org%3E
> >
> >
> > Web message: 6086a32c@news.povray.org
> >
> > ---
>
> In working with Tor Olav's idea for a more accurate VAngle macro, I
> discovered the lower case identifier checking(1) is far too expensive
> when making a million calls to a macro with internal #local identifiers.
>
> For now, I recommend configuration with --disable-no-lc-identifiers, if
> running scenes calling macros with internal identifiers a great many times.
>
> Bill P.
>
> (1) - I'm using c++11 regex at the moment. I've noted some complaints
> about performance of std regex, but whether it's that or just how our
> macros work in being re-read / interpreted on each call - I don't know.
> Might be significant expense is unavoidable and the case checking should
> not be the default behavior.

You seem to solve so many issues in that linux only branch, is there a chance
that some of those fix propagate to master or do they already? Sorry if this is
not what you were referring to at all, but  some unjustified overhead to the use
of separated pov macro files was mentioned numerous times by Clipka and
supposedly solved in his branch, just in case.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. b0bc... [1796 days 3 hours and 14 minutes ago]

Thu, 13 May 2021 12:54:12 GMT

On 4/26/21 7:42 AM, William F Pokorny wrote:
> Ref:
> 
>
http://news.povray.org/povray.binaries.programming/message/%3C6086a32c%40news.povray.org%3E/#%3C6086a32c%40news.povray.org%3E

> 
> 
> Web message: 6086a32c@news.povray.org
> 
> ---

In working with Tor Olav's idea for a more accurate VAngle macro, I 
discovered the lower case identifier checking(1) is far too expensive 
when making a million calls to a macro with internal #local identifiers.

For now, I recommend configuration with --disable-no-lc-identifiers, if 
running scenes calling macros with internal identifiers a great many times.

Bill P.

(1) - I'm using c++11 regex at the moment. I've noted some complaints 
about performance of std regex, but whether it's that or just how our 
macros work in being re-read / interpreted on each call - I don't know. 
Might be significant expense is unavoidable and the case checking should 
not be the default behavior.

[William F Pokorny] Lean toward point normal patterns (povr branch) [1799 days 3 hours and 22 minutes ago]

Mon, 10 May 2021 12:45:31 GMT

Elsewhere the idea of leaning toward a point in space as a normal 
pattern was discussed. In an initial povr branch implementation ended up 
with two forms of the pattern. One for use in averages with other 
patterns and another which comes after the zero weighted perturbed 
pattern prior that adds the lean on top of the previous perturbation. 
These are 'bevy type 3' and 'bevy type 4' below, respectively.

In the attached image the upper left corner is the original sphere with 
no normal{} perturbation. In the upper right only a lean toward +y. In 
the lower left an average of normals where one pattern wrinkles like and 
the other the lean toward point. In the lower right the second form 
which leans the already wrinkle perturbed normal to create a final 
perturbed normal.

The code for the lower two images looks like:

  ...
  average
  normal_map {
       [1 bevy type 1 bump_size 0.5]
       [1 bevy type 3 bump_size 0.5] // lean
  }
  ...

and

  ...
  average
  normal_map {
       [0 bevy type 1 bump_size 0.5]
       [1 bevy type 4 bump_size 0.5] // lean normal perturbed above
  }
  ...

where currently 'bevy' is a normal perturbation pattern really a 
collection of experimental normal patterns of which two are the leaning 
kind(1). Type 1 is a possible non-biased wrinkles replacement.

Bill P.

(1) - Wondering if types not the better way to go over keywords when 
patterns are related - otherwise the number of keywords starts to explode.

[jr] Re: An updated povr tarball for Unix/Linux. b0bc... [1807 days 7 hours and 8 minutes ago]

Sun, 2 May 2021 09:00:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/1/21 4:09 PM, jr wrote:
> > ...
> > have trouble due to one of the includes.  ...
>
> Thanks!
>
> First, in include/shapes.inc - before installing in a directory, try
> adding an include to transforms.inc just below the include for
> functions.inc so the includes at top look like:
>
> #include "functions.inc"  // <-- Dependency on povr's f_supertorus()
> #include "transforms.inc" // <-- Several transform macros are used

ok, that solved the problem.  cheers.


> ... which means ... More include macro self testing required I
> guess!

if test parameters can be "presented" as sets, stored in an array of 'array
mixed' for example, foreach might be of help automating the running.
(if there's (small) help I can provide, ask)


regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. b0bc... [1807 days 18 hours and 11 minutes ago]

Sat, 1 May 2021 21:56:45 GMT

On 5/1/21 4:09 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>> On 4/28/21 12:27 PM, jr wrote:
>>>> ...
>>> Then try the make (the compiles) again?
>>
>> worked a treat, install tonight. ...
> 
> have trouble due to one of the includes.  scene + output attached; 'logo.inc' is
> symlinked into povr's include dir.
> 
> 
> regards, jr.
>

Thanks!

First, in include/shapes.inc - before installing in a directory, try 
adding an include to transforms.inc just below the include for 
functions.inc so the includes at top look like:


#include "functions.inc"  // <-- Dependency on povr's f_supertorus()
#include "transforms.inc" // <-- Several transform macros are used

In my cut down set of core includes, I tried to have only the necessary 
includes to save on parsing time and core maintenance. I've gotten it 
wrong(1).

---
(1) - I had it in my head if I had tests including each of the shipped 
includes, I'd pick up any dependencies, but you have to actually call 
each macro and I don't yet, which means probably other include and macro 
issues are lurking. :-(  More include macro self testing required I 
guess!

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. b0bc... [1807 days 19 hours and 58 minutes ago]

Sat, 1 May 2021 20:10:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 4/28/21 12:27 PM, jr wrote:
> > > ...
> > Then try the make (the compiles) again?
>
> worked a treat, install tonight. ...

have trouble due to one of the includes.  scene + output attached; 'logo.inc' is
symlinked into povr's include dir.

regards, jr.

[Robert Nufer] Operation timed out [1809 days 1 hour and 38 minutes ago]

Fri, 30 Apr 2021 14:30:00 GMT

First of all: Many thanks to the programmers for this fantastic tool!!!

Like other users, I observe program termination with an "operation timed out"
message. This occurs, if freeing memory after complex renderings takes a long
time (more than 10 secs, also depending on other processes.)
I am using Version 3.7.0.msvc10.win64 on two computers:
PC1: Win64 Pro; 16 GB RAM, Processor Intel Core I7-4600U  @2.1 GHz,
PC2: Win64 Pro; 16 GB RAM; Processor Intel Core I9-10900K @3.7 GHz.

My complex scenes use about 9 GB of RAM, which is freed after the rendered image
is saved. Even if windos is running in safe mode without networking, sometimes
freeing memory takes longer than 10 secs... and the program stops.

This timeout value is defined in the file source\base\povms.cpp:

#define kDefaultTimeout   10

I would be happy if someone could compile povray 3.7.0 by changing the value to
a higehr value, for example:

#define kDefaultTimeout   60

Many thanks
Robert

P.S.
The attachment shows a PoV-Ray rendered model of the Moon (8'294'400 triangles)

[jr] Re: An updated povr tarball for Unix/Linux. b0bc... [1810 days 1 hour and 48 minutes ago]

Thu, 29 Apr 2021 14:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/28/21 12:27 PM, jr wrote:
> > ...
> With the jitter.h issue could you try changing the two calls to rand()
> to std::rand() (a) and then at the top of jitter.h just after the
> comment about c++ variants of c includes add an include of cstdlib so it
> looks like:
>
> // C++ variants of C standard header files
> #include <cstdlib>
>
> Then try the make (the compiles) again?

worked a treat, install tonight.  thanks.  patch attached, in case other Linux
users have use for it.


regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. b0bc... [1810 days 20 hours and 48 minutes ago]

Wed, 28 Apr 2021 19:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/28/21 12:27 PM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ...
> Thanks for trying. The --enable-silent-rules is probably not needed
> unless you've somehow overridden the tarball shipped default (...one can
> do it by various methods (the reason the enable and disable are always
> both available as configure options), but it is not common).
>
> ---
> Of course my compiles with your configure

:-)

> ...
> With the jitter.h issue could you try changing the two calls to rand()
> to std::rand() (a) and then at the top of jitter.h just after the
> comment about c++ variants of c includes add an include of cstdlib so it
> looks like:
>
> // C++ variants of C standard header files
> #include <cstdlib>
>
> Then try the make (the compiles) again?
>
> (a) - What those always should have been I think and the first thing I
> see which might be wrong. I see on searching a few more bare rand()
> calls sitting in the code too which might also cause you trouble
> compiling if this the issue (some in pattern.cpp). Hmm, wonder why those
> not an issue before for you if so...

tomorrow night.  factoid - when the alpha.10064268 was published, missing
'std::' prefixes were a problem.  cheers.


regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. b0bc... [1810 days 21 hours and 6 minutes ago]

Wed, 28 Apr 2021 19:01:30 GMT

On 4/28/21 12:27 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> ...
>> had a v quick look, pleased the INSTALL isn't just the usual generic.  will try
>> a no-SDL install in the coming days.  thank you.
> 
> tried building but got an error.
> 
...
> 
> using:
> 
>    ./configure \
>    --enable-silent-rules \
>    --without-libsdl \
>    --without-libsdl2 \
>    --disable-no-lc-identifiers \
>    --with-x \
>    --build=${ARCH}-slackware-linux \
>    COMPILED_BY="$POVRAY_BUILDER"
> 

Thanks for trying. The --enable-silent-rules is probably not needed 
unless you've somehow overridden the tarball shipped default (...one can 
do it by various methods (the reason the enable and disable are always 
both available as configure options), but it is not common).

---
Of course my compiles with your configure (and some C++ compiler 
settings you must be picking up somewhere by env var or something) and 
all work. I can't reproduce so my best guess...

With the jitter.h issue could you try changing the two calls to rand() 
to std::rand() (a) and then at the top of jitter.h just after the 
comment about c++ variants of c includes add an include of cstdlib so it 
looks like:

// C++ variants of C standard header files
#include <cstdlib>

Then try the make (the compiles) again?

(a) - What those always should have been I think and the first thing I 
see which might be wrong. I see on searching a few more bare rand() 
calls sitting in the code too which might also cause you trouble 
compiling if this the issue (some in pattern.cpp). Hmm, wonder why those 
not an issue before for you if so...

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. b0bc... [1810 days 23 hours and 38 minutes ago]

Wed, 28 Apr 2021 16:30:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> had a v quick look, pleased the INSTALL isn't just the usual generic.  will try
> a no-SDL install in the coming days.  thank you.

tried building but got an error.


regards, jr.


using:

  ./configure \
  --enable-silent-rules \
  --without-libsdl \
  --without-libsdl2 \
  --disable-no-lc-identifiers \
  --with-x \
  --build=${ARCH}-slackware-linux \
  COMPILED_BY="$POVRAY_BUILDER"


edited output from extracting archive thru 'make':

povray-3.8.0-x.povr_b0bcf6c0/
  ...
===============================================================================
POV-Ray (povr) 3.8.0-x.povr_b0bcf6c0 has been configured.
===============================================================================

Built-in features:
  I/O restrictions:          enabled
  X/SDL Window display:      enabled (sdl not available)
  Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
  Unsupported image formats: -

Compilation settings:
  Build architecture:  x86_64-slackware-linux-gnu
  Built/Optimized for: x86_64-slackware-linux-gnu
  Compiler vendor:     gnu
  Compiler version:    g++ 5.5.0

  Preprocessor flags (CPPFLAGS):
    -pthread -I/usr/include/OpenEXR -I/usr/include

  Compiler flags (CXXFLAGS):
    -pipe -w -fno-enforce-eh-specs -std=c++11 -march=native -mtune=haswell -O2
    -fPIC -pthread

  Linker flags (LDFLAGS):
    -L/usr/lib

  Libraries (LIBS):
    -lXpm -lSM -lICE -lX11 -lIlmImf -lIlmImf -lImath -lHalf -lIex -lIexMath
    -lIlmThread -pthread -lIlmThread -ltiff -ljpeg -lpng -lz -lrt -lm -pthread

  ...
make  all-recursive
make[1]: Entering directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0'
Making all in source
make[2]: Entering directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0/source'
  CXX      povmain.o
  CXX      backend/bounding/boundingtask.o
  CXX      backend/control/messagefactory.o
  ...
  CXX      core/math/chi2.o
  CXX      core/math/hypercomplex.o
  CXX      core/math/jitter.o
In file included from [01m[Kcore/math/jitter.cpp:37:0[m[K:
[01m[K../source/core/math/jitter.h:[m[K In function ‘[01m[Kvoid
pov::Jitter2d(double, double, double&, double&)[m[K’:
[01m[K../source/core/math/jitter.h:104:43:[m[K [01;31m[Kerror:
[m[K‘[01m[Krand[m[K’ was not declared in this scope
     jx = -0.5f + static_cast<double>(rand()) /
(static_cast<double>(RAND_MAX/((0.5)-(-0.5f))));
[01;32m[K                                           ^[m[K
[01m[K../source/core/math/jitter.h:104:69:[m[K [01;31m[Kerror:
[m[K‘[01m[KRAND_MAX[m[K’ was not declared in this scope
     jx = -0.5f + static_cast<double>(rand()) /
(static_cast<double>(RAND_MAX/((0.5)-(-0.5f))));
[01;32m[K
^[m[K
Makefile:1309: recipe for target 'core/math/jitter.o' failed
make[2]: *** [core/math/jitter.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0/source'
Makefile:707: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/POV/povray-3.8.0-x.povr_b0bcf6c0'
Makefile:500: recipe for target 'all' failed
make: *** [all] Error 2

[jr] Re: An updated povr tarball for Unix/Linux. b0bc... [1813 days 3 hours and 28 minutes ago]

Mon, 26 Apr 2021 12:40:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Ref: {...}
> A note on this release of the povr branch of POV-Ray. In reworking the
> autotools build I pulled all the decades old automatic optimizations.
> This means for good performance you have to specify the optimizations
> during the configuration.
>
> A collection of configuration examples can be found in the INSTALL.txt
> files, but for many this one enabling link time optimization will work:
>
> ./configure -q COMPILED_BY="me" \
> CXXFLAGS="-std=c++17 -O3 -ffast-math -march=native" \
> --enable-lto LDFLAGS="-s"

had a v quick look, pleased the INSTALL isn't just the usual generic.  will try
a no-SDL install in the coming days.  thank you.


regards, jr.

[William F Pokorny] An updated povr tarball for Unix/Linux. b0bcf6c0 [1813 days 4 hours and 25 minutes ago]

Mon, 26 Apr 2021 11:42:51 GMT

Ref:

http://news.povray.org/povray.binaries.programming/message/%3C6086a32c%40news.povray.org%3E/#%3C6086a32c%40news.povray.org%3E

Web message: 6086a32c@news.povray.org

---

A note on this release of the povr branch of POV-Ray. In reworking the 
autotools build I pulled all the decades old automatic optimizations. 
This means for good performance you have to specify the optimizations
during the configuration.

A collection of configuration examples can be found in the INSTALL.txt 
files, but for many this one enabling link time optimization will work:

./configure -q COMPILED_BY="me" \
CXXFLAGS="-std=c++17 -O3 -ffast-math -march=native" \
--enable-lto LDFLAGS="-s"

Bill P.

[Cousin Ricky] Re: Sniffing UberPOV [1861 days 21 hours and 38 minutes ago]

Mon, 8 Mar 2021 18:30:17 GMT

On 2021-03-06 6:53 PM (-4), Bald Eagle wrote:
> "Mr" <nomail@nomail> wrote:
> 
>>> My first (and so far only) idea was to start with a test for the
>>> existence of the variable 'unofficial', but it turns out POV-Ray 3.8
>>> does the same test--but treats it as if it were a keyword.  This screws
>>> up the test for any SDL code running under 3.8.
>>
>> Yes.
>> I believe you're searching for the combination of this :
>>
>> #ifdef(unofficial)
>>
>> with a more narrowed patch version number that belongs only to uber pov such as:
>>
>> #if(unofficial = \"patch\") #if(patch(\"upov-reflection-roughness\") > 0)
> 
> 
> in qtpovray3.8:
> 
> #ifdef (unofficial)
> Parse Warning: Trying to test whether a reserved keyword is defined. Test result
> may not be what you expect.
> #declare U = unofficial;
> Parse Error: Expected 'RValue to declare', unofficial found instead
> #declare P = patch;
> Parse Error: Cannot pass uninitialized identifier to non-optional LValue.
> #debug unofficial
> Parse Error: Expected 'string expression', unofficial found instead
> #debug patch
> Parse Error: Expected 'string expression', undeclared identifier 'patch' found
> instead

Exactly.  The results are the same in official POV-Ray 3.8.  The problem 
is that the test on 'unofficial' is reliable _only_ with a patch that 
uses it--which is exactly what we don't know in advance; and any further 
refined tests are pointless.

I'll just go ahead and assume that the user is using official POV-Ray, 
and have them set a flag variable if they are using a 3.7.1-based patch.

[Bald Eagle] Re: Sniffing UberPOV [1863 days 17 hours and 13 minutes ago]

Sat, 6 Mar 2021 22:55:00 GMT

"Mr" <nomail@nomail> wrote:

> > My first (and so far only) idea was to start with a test for the
> > existence of the variable 'unofficial', but it turns out POV-Ray 3.8
> > does the same test--but treats it as if it were a keyword.  This screws
> > up the test for any SDL code running under 3.8.
>
> Yes.
> I believe you're searching for the combination of this :
>
> #ifdef(unofficial)
>
> with a more narrowed patch version number that belongs only to uber pov such as:
>
> #if(unofficial = \"patch\") #if(patch(\"upov-reflection-roughness\") > 0)

in qtpovray3.8:

#ifdef (unofficial)
Parse Warning: Trying to test whether a reserved keyword is defined. Test result
may not be what you expect.
#declare U = unofficial;
Parse Error: Expected 'RValue to declare', unofficial found instead
#declare P = patch;
Parse Error: Cannot pass uninitialized identifier to non-optional LValue.
#debug unofficial
Parse Error: Expected 'string expression', unofficial found instead
#debug patch
Parse Error: Expected 'string expression', undeclared identifier 'patch' found
instead

[Mr] Re: Sniffing UberPOV [1863 days 18 hours and 28 minutes ago]

Sat, 6 Mar 2021 21:40:00 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> Does anyone know whether it is possible for a scene file to detect
> whether or not it is being rendered by UberPOV, without bombing out if
> it is rendered by official POV-Ray?
>
> Why would I need to do this?  Because I'm writing a macro that needs to
> know whether or not true inverse square light attenuation is available.
> For official POV-Ray, this is version >= 3.8, but for UberPOV, it is
> version >= 3.71.
>
> My first (and so far only) idea was to start with a test for the
> existence of the variable 'unofficial', but it turns out POV-Ray 3.8
> does the same test--but treats it as if it were a keyword.  This screws
> up the test for any SDL code running under 3.8.

Yes.
I believe you're searching for the combination of this :

#ifdef(unofficial)

with a more narrowed patch version number that belongs only to uber pov such as:

#if(unofficial = \"patch\") #if(patch(\"upov-reflection-roughness\") > 0)

[Cousin Ricky] Sniffing UberPOV [1865 days and 14 minutes ago]

Fri, 5 Mar 2021 15:54:07 GMT

Does anyone know whether it is possible for a scene file to detect 
whether or not it is being rendered by UberPOV, without bombing out if 
it is rendered by official POV-Ray?

Why would I need to do this?  Because I'm writing a macro that needs to 
know whether or not true inverse square light attenuation is available. 
For official POV-Ray, this is version >= 3.8, but for UberPOV, it is 
version >= 3.71.

My first (and so far only) idea was to start with a test for the 
existence of the variable 'unofficial', but it turns out POV-Ray 3.8 
does the same test--but treats it as if it were a keyword.  This screws 
up the test for any SDL code running under 3.8.

[Mr] Re: Hgpovray38, current state [1868 days 23 hours and 38 minutes ago]

Mon, 1 Mar 2021 16:30:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 28/02/2021 Ã  23:15, Mr a Ã©critÂ :
> > Hi, I made yet another attempt at building on Windows with other parameters and
> > received different warnings mentioning :
> >
> > unknown type name '__m64'
> >
> > Is there any chance to replace / enhance definition of this in the source code
> > with something more cross platform  ?
> >
> >
> >
>
> Can you elaborate a bit more (location of the error ?) ?
>
> What is puzzling is that something like __m64 starts with double
> underscore and that is something which should be reserved to compiler
> implementation.
>
> Any capture of the full message

 Indeed includes belonged to LLVM /CLANG 10 for VC... The thing is I know too
little, especially about expected options and get lost in trial and errors.

A few clues or reminders of what "should" normally  be the best options could
help me to get there quicker. (Using a Windows 10 with an I7 CPU) current
settings: when loading a file I let it update toolset from v140 to version142

Configuration: Debug, Platform: x64
Windows SDK version 10 ... Better with the default of 8.1?
Floating point mode Precise... Better with strict or fast?

MFC: Use Standard Windows Libraries... Better with use MFC from a static
library? or from a shared dll?
Desactivate language extensions : Yes (/Za)... ok?
iso norm for C version?  trying with MSVC inherited... Better with C 11 or C 17?
iso norm for C++ version?  trying with default std C++14 (nothing older)...
Better with 17 or "latest"?

Character set currently undefined  in project file, better with unicode or MBCS?

No Common Language Runtime

Compile as C++(/TP) ... Better with compile as C Code (/TC)?
With that, I get all the errors mentionned in this discussion, so I stopped
assuming that the code should not be touched and am about to start again to the
suggested changes. I was only searching for a working build setup witout it
first : so I now switched the toolset from Visual Studio 2019 (v142) to LLVM
(clang-cl).. better with LLVM? any clues?

[Le Forgeron] Re: Hgpovray38, current state [1869 days 4 hours and 11 minutes ago]

Mon, 1 Mar 2021 11:56:51 GMT

Le 28/02/2021 Ã  23:15, Mr a Ã©critÂ :
> Hi, I made yet another attempt at building on Windows with other parameters and
> received different warnings mentioning :
> 
> unknown type name '__m64'
> 
> Is there any chance to replace / enhance definition of this in the source code
> with something more cross platform  ?
> 
> 
> 

Can you elaborate a bit more (location of the error ?) ?

What is puzzling is that something like __m64 starts with double
underscore and that is something which should be reserved to compiler
implementation.

Any capture of the full message ?

[Mr] Re: Hgpovray38, current state [1869 days 17 hours and 48 minutes ago]

Sun, 28 Feb 2021 22:20:00 GMT

Hi, I made yet another attempt at building on Windows with other parameters and
received different warnings mentioning :

unknown type name '__m64'

Is there any chance to replace / enhance definition of this in the source code
with something more cross platform  ?

[Bald Eagle] Re: povr / hgpovray38 / pov-ray 4 (was Re: Spira... [1872 days 3 hours and 58 minutes ago]

Fri, 26 Feb 2021 12:10:01 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> > Aside: I am mostly busy with real life for a bit (a week?). I need to do
> > my US taxes

Don't worry Bill, the income tax, an unConstitutional unapportioned direct tax
is merely a temporary wartime measure.   Just like the 14 day lockdown to
"flatten the curve".  :|

Government: You owe us money.
Citizen: I do? How much do I owe?
Government: YOU have to figure that out.
Citizen: So, I just pay what I want?
Government: No - we know _exactly_ how much you owe, but it's up to you to
figure out how much that is.
Citizen: What if I get it wrong?
Government: You go to prison.

> Please go on posting about povr (and Le_Forgeron about hgpovray38)
> wherever you see the necessity. Those are important works which I follow
> with interest, even if most of the time the content goes way over my
> head. ;-)  I see them as beachheads for any future version of POV-Ray,
> even an official version 3.8, but certainly higher, being that 4.0 or
> 3.9+. Keep up the good work!

Yes indeed.  All of the summaries and ponderings, and unravelings of existing
code are instructive - they provide a peek under the hood, familiarize me with
the thought processes and caveats involved in source-side raytracing, and
illustrate the problems, tradeoffs, and solutions.  Things I may not have
understood 5 years ago, I will often find myself referencing multiple times as I
toy with new ideas and leap out off the edge in reckless pursuit of new
knowledge.  :D

> In the meantime, there is the matter of all the current includes files
> to consider too for instance, as I was made aware of again. I would
> gladly contribute to their upgrading to more modern standards where
> textures and such are concerned.

Hopefully most things like this will be some simple elimination of ambient in
finishes, and other things that can be quickly addressed with some good old
find-and-replace.

> However, I have some misgivings about
> my role as I know that health issues in my close family environment in
> the (near) future may seriously hamper or stop my contribution. Otoh, I
> always could start something of course and see where it leads me...

Good luck with the health issues - they catch up to us all no matter what we do.

[Thomas de Groot] Re: povr / hgpovray38 / pov-ray 4 (was Re: Spira... [1872 days 8 hours and 23 minutes ago]

Fri, 26 Feb 2021 07:44:22 GMT

Op 25/02/2021 om 16:33 schreef William F Pokorny:
> On 2/22/21 11:40 AM, Le_Forgeron wrote:
>> Le 22/02/2021 Ã  08:43, Thomas de Groot a Ã©critÂ :
>>
>>> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
>>> POV-Ray 4 stands for? I am lost about the history of that ng.
>>>
>>
> ...
>>
>> I do not know if there is any correlation between pov4 and povr.
> 
> None.
> 
> My povr branch implements some things 'I' think should be part of any 
> povray 4.0.
> 
>>
>> For me, povr (as well as hgpovray38) is a divergent work from official
>> povray (3.8 not yet published), so it would have been better to continue
>> in p.u.patches .
>>
> 
> The povr branch has only been 'published' as a patch/tarball.
> 
> I've been mentioning the work in other newsgroups when I think it helps 
> along a POV-Ray discussions or when a povr update has been driven by a 
> bug or discussion in some newsgroup.
> 
> It's also true I've borrowed the povray.beta-test.binaries newsgroup to 
> publish some of the functionality. In not being mirrored to the web 
> interface that group mostly doesn't show up to regular users, but was 
> thinking my 'ideas' for the future are at least documented in a place 
> later povray developers can find along with code in an occasionally 
> published tar ball.
> 
> ...I see on coming back, discussions in other newsgroups where I could 
> chime in with detail and stuff only povr at the moment can do - though 
> much of the basic infrastructure is there in POV-Ray already.
> 
> But, I see your point too. Mention of povr, other than here, is 
> confusing and noise to all but a 'very few' users. Unlike your branch 
> and Dick's, the povr branch is not in total compatible with v3.8 master.
> 
> I'll aim to limit povr mentions to this newsgroup. I'll still put 
> tarballs in povray.binaries.programming when I happen to get something 
> together.
> 
> No one should take povr as other than my personal branch!
> 
> Aside: I am mostly busy with real life for a bit (a week?). I need to do 
> my US taxes :-( Plus, get after some other too long put off tasks about 
> the home.
> 
> Bill P.
> 
> 

Please go on posting about povr (and Le_Forgeron about hgpovray38) 
wherever you see the necessity. Those are important works which I follow 
with interest, even if most of the time the content goes way over my 
head. ;-)  I see them as beachheads for any future version of POV-Ray, 
even an official version 3.8, but certainly higher, being that 4.0 or 
3.9+. Keep up the good work!

In the meantime, there is the matter of all the current includes files 
to consider too for instance, as I was made aware of again. I would 
gladly contribute to their upgrading to more modern standards where 
textures and such are concerned. However, I have some misgivings about 
my role as I know that health issues in my close family environment in 
the (near) future may seriously hamper or stop my contribution. Otoh, I 
always could start something of course and see where it leads me...

[Good luck with the taxes. Mine (NL) are coming up next month.]

-- 
Thomas

[William F Pokorny] Re: povr / hgpovray38 / pov-ray 4 (was Re: Spira... [1873 days and 34 minutes ago]

Thu, 25 Feb 2021 15:33:20 GMT

On 2/22/21 11:40 AM, Le_Forgeron wrote:
> Le 22/02/2021 Ã  08:43, Thomas de Groot a Ã©critÂ :
> 
>> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
>> POV-Ray 4 stands for? I am lost about the history of that ng.
>>
> 
...
> 
> I do not know if there is any correlation between pov4 and povr.

None.

My povr branch implements some things 'I' think should be part of any 
povray 4.0.

> 
> For me, povr (as well as hgpovray38) is a divergent work from official
> povray (3.8 not yet published), so it would have been better to continue
> in p.u.patches .
> 

The povr branch has only been 'published' as a patch/tarball.

I've been mentioning the work in other newsgroups when I think it helps 
along a POV-Ray discussions or when a povr update has been driven by a 
bug or discussion in some newsgroup.

It's also true I've borrowed the povray.beta-test.binaries newsgroup to 
publish some of the functionality. In not being mirrored to the web 
interface that group mostly doesn't show up to regular users, but was 
thinking my 'ideas' for the future are at least documented in a place 
later povray developers can find along with code in an occasionally 
published tar ball.

...I see on coming back, discussions in other newsgroups where I could 
chime in with detail and stuff only povr at the moment can do - though 
much of the basic infrastructure is there in POV-Ray already.

But, I see your point too. Mention of povr, other than here, is 
confusing and noise to all but a 'very few' users. Unlike your branch 
and Dick's, the povr branch is not in total compatible with v3.8 master.

I'll aim to limit povr mentions to this newsgroup. I'll still put 
tarballs in povray.binaries.programming when I happen to get something 
together.

No one should take povr as other than my personal branch!

Aside: I am mostly busy with real life for a bit (a week?). I need to do 
my US taxes :-( Plus, get after some other too long put off tasks about 
the home.

Bill P.

[William F Pokorny] Re: Spiral Warp [1873 days 1 hour and 35 minutes ago]

Thu, 25 Feb 2021 14:33:07 GMT

On 2/21/21 12:07 PM, Le_Forgeron wrote:
> Le 21/02/2021 Ã  15:10, William F Pokorny a Ã©critÂ :
...
> 
> Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
> a fully painful set of constraints, on the rewrite of the old C object
> oriented code (from the very old code in 3.1). It is more than just C++.
> 

Thanks. I didn't know the where he was getting the 'extremely robust' 
set of constraints. Even as the rules are represented in in the code 
source I believe they nearly impossible to follow completely without 
some kind of automation - and I see there was the ability to integrate 
those rules as checks in perforce itself. Had you guys done that?

Bill P.

[Dick Balaska] Re: qtpovray 3.80.15 [1873 days 18 hours ago]

Wed, 24 Feb 2021 22:08:03 GMT

On 2/22/2021 4:51 AM, Mike Horvath wrote:

> 
> 
> Also, how do I change the folder for this stuff to the "Public" user 
> instead of my admin user. Thanks.
> 
> 
> Mike

The installer should have selected your Documents directory.  (I did see 
it pick admin once in testing, but I thought that was fixed.)

During install, there was a place where it asked what directory to 
install to.

qtpovray doesn't really use the register.  For povray sdl, the important 
thing is the root directory when you created the workspace.  For the 
help, includes, and inserts, those can be changed in the configure dialog.

I'm working on making the Windows ini usage of qtpovray more consistent 
with POV-Ray for Windows.

-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[Thomas de Groot] Re: povr / hgpovray38 / pov-ray 4 (was Re: Spira... [1874 days 8 hours and 36 minutes ago]

Wed, 24 Feb 2021 07:31:50 GMT

Op 23/02/2021 om 12:48 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Yes, I understand that, but my question (out of sheer curiosity) was
>> what, historically, 'POV-Ray 4' was intended to be. I guess it was the
>> next future version of POV, but the newsgroup 'pov4.discussion.general',
>> over the years, seems to be filled with unrelated topics. So, I wondered
>> how povr and hgpovray38 relate to that mythical pov4? Are they
>> intermediary steps or are they the intended as the 'real thing'? Just
>> idle questions from a guy who has nothing better to do ;-)
> 
> Well, unless someone can provide a clear and unambiguous historical answer, I'd
> say that whatever the intention was, it's lost to history.
> 
> I'd say that probably what we're looking for gets broken down into speed,
> reliability, and functionality.
> 
> So, then we make ourselves an outline, and start making entries under those
> headings.
> 
> 1. What can be made faster / what really NEEDS (realistically) to be faster?
> 2. What are the parts of POV-Ray that are unstable/unreliable?
> 3. And functionality -
> which I think can be broken down into 3 parts
>    A. programming / math - because as much as POV-Ray is a renderer,
>       it primarily relies on SDL code to generate the content
>       So, data types/containers, algorithms, mathematical functions
> 
>    B. scene assembly / modeling
>       this can be split up into geometry and texturing,
>       and of course we have other things like camera, lighting, etc
>       ...and the parser.
> 
>    C. rendering
>       Likely much of this will be things like ray-object intersections
>       and related things that Bill Pokorny is up to his eyeballs in
> 
> 
> clipka had some things to say about some of this here:
> 
>
http://news.povray.org/povray.general/thread/%3C49ca3d4e%241%40news.povray.org%3E/?mtop=305193&moff=10
> 
> So maybe one single thread can be set aside to post nothing but the barest
> descriptive entries, with a meta-thread dedicated to commentary and discussion.
> The we can see where we're at, and where it would be productive for people to go
> and do.
> 
> Plus, it would provide an easy list to refer to when sifting through the forums
> for code that already accomplishes (mostly) what is on the wish list.
> 
> Because 4.0 was supposed to be a break from the slow bureaucratic suicide of
> backwards-compatibility - so since we're the only ones using POV-Ray, and HERE,
> guess who decides what 4.0, if it's ever going to get made, will be?
>

Right! Very clear indeed; I didn't remember that post by Christoph and 
he says some very fundamental things too. I need to ponder this a bit 
more...

-- 
Thomas

[Bald Eagle] Re: povr / hgpovray38 / pov-ray 4 (was Re: Spira... [1875 days 4 hours and 18 minutes ago]

Tue, 23 Feb 2021 11:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:

> Yes, I understand that, but my question (out of sheer curiosity) was
> what, historically, 'POV-Ray 4' was intended to be. I guess it was the
> next future version of POV, but the newsgroup 'pov4.discussion.general',
> over the years, seems to be filled with unrelated topics. So, I wondered
> how povr and hgpovray38 relate to that mythical pov4? Are they
> intermediary steps or are they the intended as the 'real thing'? Just
> idle questions from a guy who has nothing better to do ;-)

Well, unless someone can provide a clear and unambiguous historical answer, I'd
say that whatever the intention was, it's lost to history.

I'd say that probably what we're looking for gets broken down into speed,
reliability, and functionality.

So, then we make ourselves an outline, and start making entries under those
headings.

1. What can be made faster / what really NEEDS (realistically) to be faster?
2. What are the parts of POV-Ray that are unstable/unreliable?
3. And functionality -
which I think can be broken down into 3 parts
  A. programming / math - because as much as POV-Ray is a renderer,
     it primarily relies on SDL code to generate the content
     So, data types/containers, algorithms, mathematical functions

  B. scene assembly / modeling
     this can be split up into geometry and texturing,
     and of course we have other things like camera, lighting, etc
     ...and the parser.

  C. rendering
     Likely much of this will be things like ray-object intersections
     and related things that Bill Pokorny is up to his eyeballs in

clipka had some things to say about some of this here:

http://news.povray.org/povray.general/thread/%3C49ca3d4e%241%40news.povray.org%3E/?mtop=305193&moff=10

So maybe one single thread can be set aside to post nothing but the barest
descriptive entries, with a meta-thread dedicated to commentary and discussion.
The we can see where we're at, and where it would be productive for people to go
and do.

Plus, it would provide an easy list to refer to when sifting through the forums
for code that already accomplishes (mostly) what is on the wish list.

Because 4.0 was supposed to be a break from the slow bureaucratic suicide of
backwards-compatibility - so since we're the only ones using POV-Ray, and HERE,
guess who decides what 4.0, if it's ever going to get made, will be?

[Thomas de Groot] Re: povr / hgpovray38 / pov-ray 4 (was Re: Spira... [1875 days 8 hours and 33 minutes ago]

Tue, 23 Feb 2021 07:34:54 GMT

Op 22/02/2021 om 17:40 schreef Le_Forgeron:
> Le 22/02/2021 Ã  08:43, Thomas de Groot a Ã©critÂ :
> 
>> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
>> POV-Ray 4 stands for? I am lost about the history of that ng.
>>
> 
> I tried to redirect to a more suitable group the discussion started in
> p.b.animations about povr & hgpovray38.
> 
> I forgot to update the subject line, and place a FU2 notice too.
> 
> I do not know if there is any correlation between pov4 and povr.
> 
> For me, povr (as well as hgpovray38) is a divergent work from official
> povray (3.8 not yet published), so it would have been better to continue
> in p.u.patches .
> 

Yes, I understand that, but my question (out of sheer curiosity) was 
what, historically, 'POV-Ray 4' was intended to be. I guess it was the 
next future version of POV, but the newsgroup 'pov4.discussion.general', 
over the years, seems to be filled with unrelated topics. So, I wondered 
how povr and hgpovray38 relate to that mythical pov4? Are they 
intermediary steps or are they the intended as the 'real thing'? Just 
idle questions from a guy who has nothing better to do ;-)

-- 
Thomas

[Le Forgeron] povr / hgpovray38 / pov-ray 4 (was Re: Spiral Wa... [1875 days 23 hours and 27 minutes ago]

Mon, 22 Feb 2021 16:40:50 GMT

Le 22/02/2021 Ã  08:43, Thomas de Groot a Ã©critÂ :

> Just out of curiosity: How is this related to "POV-Ray 4" or whatever
> POV-Ray 4 stands for? I am lost about the history of that ng.
> 

I tried to redirect to a more suitable group the discussion started in
p.b.animations about povr & hgpovray38.

I forgot to update the subject line, and place a FU2 notice too.

I do not know if there is any correlation between pov4 and povr.

For me, povr (as well as hgpovray38) is a divergent work from official
povray (3.8 not yet published), so it would have been better to continue
in p.u.patches .

[Mike Horvath] Re: qtpovray 3.80.15 [1876 days 6 hours and 17 minutes ago]

Mon, 22 Feb 2021 09:51:09 GMT

On 2/12/2021 10:16 PM, Dick Balaska wrote:
> On 2/7/2021 12:40 AM, Mike Horvath wrote:
>> I am a first time qtpovray user.
>>
>> Does the program not use an INI file for settings?
>>
>> How do I set up multiple include paths?
>>
>> Thanks.
>>
>>
>> Mike
> 
> Um, erm, I guess I didn't really set that up properly.
> 
> On my box, it is looking for
> SYSINI = C:/Users/dick/Documents\qtpovray\v3.8\ini\povray.ini
> but it doesn't exist and I don't care.Â  I guess I should.
> 


Also, how do I change the folder for this stuff to the "Public" user 
instead of my admin user. Thanks.


Mike

[Mike Horvath] Re: qtpovray 3.80.15 [1876 days 6 hours and 26 minutes ago]

Mon, 22 Feb 2021 09:41:49 GMT

On 2/12/2021 10:16 PM, Dick Balaska wrote:
> On 2/7/2021 12:40 AM, Mike Horvath wrote:
>> I am a first time qtpovray user.
>>
>> Does the program not use an INI file for settings?
>>
>> How do I set up multiple include paths?
>>
>> Thanks.
>>
>>
>> Mike
> 
> Um, erm, I guess I didn't really set that up properly.
> 
> On my box, it is looking for
> SYSINI = C:/Users/dick/Documents\qtpovray\v3.8\ini\povray.ini
> but it doesn't exist and I don't care.Â  I guess I should.
> 

A menu to pick whatever INI file I want like in standard POV-Ray for 
Windows would be nice to have. Thanks!


Mike

[Thomas de Groot] Re: Spiral Warp [1876 days 8 hours and 24 minutes ago]

Mon, 22 Feb 2021 07:43:44 GMT

Op 21/02/2021 om 18:07 schreef Le_Forgeron:
> Le 21/02/2021 Ã  15:10, William F Pokorny a Ã©critÂ :
>> On 2/21/21 6:03 AM, Le_Forgeron wrote:
>>> Le 19/02/2021 Ã  00:32, Bald Eagle a Ã©critÂ :
>>>>>
>>>>> Do you have some commercials for povr ?
>>>>>
>>>>> I mean some catalog of all the features that povr has ?
>>>>
>>>> I think that may mean "You should consider doing an hgpovray38 version."
>>>> Which, I think, is an excellent idea.Â  :D
>>>>
>>>
>>> The catalog for hgpovray38 is in the wiki.
>>> (as well as illustrated in the distribution, but that's only after
>>> download, so not a real advertisement)
>>>
>>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>>
>>> I'm lacking such information about povr.
>>>
>>
>> As am I currently for any concise form for the whole.
>>
>> ---
>>
>> I'm struggling with how to document. I have no plans to continue to use
>> the wiki though a chunk of my early documentation is there, if you look.
>> The wiki method is too slow to use and not under code control.
>> [SNIP]
> I tried to use the github wiki (separate repository, tied to the
> project), but it was painful (especially with dual repository in github
> & bitbucket). So I returned to povray.wiki.
> 
> If you like documentation in code control, there is the md files which
> could be used (but focus on supported features by github, forget fancy
> options). Everything starts at README.md,
> 
>> The povr branch is based off of v3.8, but it's absolutely a break from
>> strong backward compatibility. Mostly, this is because it's all I can
>> manage - but I also think it's necessary to fix many of the long
>> standing issues! There are hundreds of fixes little and large in povr. I
>> think too often today's documented features are not really working as
>> they should! Is adding many new features on such a base the best
>> immediate path forward?
>>
> 
> Stalled fixing, or adding needed stuff, large dilemma.
> I answered for myself when CLipka starts rewriting a lot of the code and
> moved files. One cook in the kitchen is enough.
> 
>> Aside: I'm only four years getting into c++ when it takes 10 to be
>> really good at anything. I'd probably be much further along if I'd long
>> been a c++ programmer. As a language c++ is nothing if not a huge
>> mountain to climb all by itself... :-( Let alone all our own classes and
>> template classes.)
>>
> 
> Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
> a fully painful set of constraints, on the rewrite of the old C object
> oriented code (from the very old code in 3.1). It is more than just C++.
> 
>> Anyway. Me rambling. The povr branch is my strong push toward what I
>> think 'POV-Ray' should be in the future, but there is no doubt, it's
>> more than I can handle in any short term time frame.
>>
>> FYI. I'm away from my computer for the next few days.
>>
>> Bill P.
>>
> 
> 
> 

Just out of curiosity: How is this related to "POV-Ray 4" or whatever 
POV-Ray 4 stands for? I am lost about the history of that ng.

-- 
Thomas

[Le Forgeron] Re: Spiral Warp [1876 days 23 hours and 1 minute ago]

Sun, 21 Feb 2021 17:07:02 GMT

Le 21/02/2021 Ã  15:10, William F Pokorny a Ã©critÂ :
> On 2/21/21 6:03 AM, Le_Forgeron wrote:
>> Le 19/02/2021 Ã  00:32, Bald Eagle a Ã©critÂ :
>>>>
>>>> Do you have some commercials for povr ?
>>>>
>>>> I mean some catalog of all the features that povr has ?
>>>
>>> I think that may mean "You should consider doing an hgpovray38 version."
>>> Which, I think, is an excellent idea.Â  :D
>>>
>>
>> The catalog for hgpovray38 is in the wiki.
>> (as well as illustrated in the distribution, but that's only after
>> download, so not a real advertisement)
>>
>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>
>> I'm lacking such information about povr.
>>
> 
> As am I currently for any concise form for the whole.
> 
> ---
> 
> I'm struggling with how to document. I have no plans to continue to use
> the wiki though a chunk of my early documentation is there, if you look.
> The wiki method is too slow to use and not under code control.
> [SNIP]
I tried to use the github wiki (separate repository, tied to the
project), but it was painful (especially with dual repository in github
& bitbucket). So I returned to povray.wiki.

If you like documentation in code control, there is the md files which
could be used (but focus on supported features by github, forget fancy
options). Everything starts at README.md,

> The povr branch is based off of v3.8, but it's absolutely a break from
> strong backward compatibility. Mostly, this is because it's all I can
> manage - but I also think it's necessary to fix many of the long
> standing issues! There are hundreds of fixes little and large in povr. I
> think too often today's documented features are not really working as
> they should! Is adding many new features on such a base the best
> immediate path forward?
> 

Stalled fixing, or adding needed stuff, large dilemma.
I answered for myself when CLipka starts rewriting a lot of the code and
moved files. One cook in the kitchen is enough.

> Aside: I'm only four years getting into c++ when it takes 10 to be
> really good at anything. I'd probably be much further along if I'd long
> been a c++ programmer. As a language c++ is nothing if not a huge
> mountain to climb all by itself... :-( Let alone all our own classes and
> template classes.)
> 

Beware, CLipka (I believe) was applying Misra/Autosar C++ coding rules,
a fully painful set of constraints, on the rewrite of the old C object
oriented code (from the very old code in 3.1). It is more than just C++.

> Anyway. Me rambling. The povr branch is my strong push toward what I
> think 'POV-Ray' should be in the future, but there is no doubt, it's
> more than I can handle in any short term time frame.
> 
> FYI. I'm away from my computer for the next few days.
> 
> Bill P.
>

[Dick Balaska] Re: qtpovray 3.80.15 [1885 days 12 hours and 51 minutes ago]

Sat, 13 Feb 2021 03:16:18 GMT

On 2/7/2021 12:40 AM, Mike Horvath wrote:
> I am a first time qtpovray user.
> 
> Does the program not use an INI file for settings?
> 
> How do I set up multiple include paths?
> 
> Thanks.
> 
> 
> Mike

Um, erm, I guess I didn't really set that up properly.

On my box, it is looking for
SYSINI = C:/Users/dick/Documents\qtpovray\v3.8\ini\povray.ini
but it doesn't exist and I don't care.  I guess I should.

-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[Alain Martel] Re: qtpovray 3.80.15 [1890 days 1 hour ago]

Mon, 8 Feb 2021 15:08:01 GMT

Le 2021-02-07 Ã  00:40, Mike Horvath a Ã©critÂ :
> I am a first time qtpovray user.
> 
> Does the program not use an INI file for settings?
> 
> How do I set up multiple include paths?
> 
> Thanks.
> 
> 
> Mike

Under Windows, any current version.

In povray.imi, you need something like this :
Library_Path="C:\Users\<user>\POV Images"

You can have any number of Â«Library_PathÂ», and they'll be
explored in order.

And, in pvengine.ini, lines like this :
[Permitted Input Paths]
1=%INSTALLDIR%
2=%PROFILEDIR%
3=%FONTDIR%
4="C:\Users\<user>\POV Images"

The first 3 lines shoupd already be present. Don't change them.
The paths here must match those added in povray.ini.

The paths in povray.ini tell where to look.
The paths in pvengine.ini tell where you are allowed to look.



Alain

[Mike Horvath] Re: qtpovray 3.80.15 [1891 days 10 hours and 28 minutes ago]

Sun, 7 Feb 2021 05:40:01 GMT

I am a first time qtpovray user.

Does the program not use an INI file for settings?

How do I set up multiple include paths?

Thanks.


Mike

[Dick Balaska] qtpovray 3.80.15 [1898 days 9 hours and 36 minutes ago]

Sun, 31 Jan 2021 06:32:13 GMT

https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.15
https://launchpad.net/~qtpovray/+archive/ubuntu/qtpovray

Bug 27 - Release qtpovray for Windows
Bug 28 - Release qtpovray for Ubuntu 20, focal


So, my wife bought me this nifty new box (16 cores 32GB 2TB SSD) with 
the condition that I play steam games with her.  Hello Windows 10!
I had to get qtpovray running on Windows again (clipka removed 
boost::thread) and I made an installer for it.

Some rando facebook messengered me saying he couldn't get the ppa for 
Ubuntu 18 to work in Ubuntu 20.  So there's that build too.


-- 
dik
Rendered 50,081,587,200 of 50,081,587,200 pixels (100%)

[William F Pokorny] Re: Performance issue with preview and sdl2.0. [1923 days 2 hours and 49 minutes ago]

Wed, 6 Jan 2021 13:18:51 GMT

On 11/1/20 8:56 AM, William F Pokorny wrote:
> A notice for folks running hgpovray38 or povr.
> 
> On my Ubuntu 20.4.1 system just tripped on a significant performance 
> issue with the preview feature when using the Simple DirectMedia Layer 
> 2.0 version. SDL2.0 the usual default, if the library is available when 
> compiling.
> 

This issue appears to be tangled with a Gnome issue. Updates in the thread:

http://news.povray.org/povray.unix/thread/%3C5fd2417b%241%40news.povray.org%3E/

Bill P.

[Mr] Re: Hgpovray38, current state [1976 days 23 hours and 53 minutes ago]

Fri, 13 Nov 2020 16:15:01 GMT

"Mr" <nomail@nomail> wrote:
> >
> > Is there maybe some library that I could change to more recent version? (I
> > already pushed many errors by replacing boost folder... But maybe I want too far
> > with that one in a too recent version?
>
> Adding :
> -Wno-c++11-narrowing
>
> into additional compiler options seems to have solved that... next issues coming
> soon :-)


It now tells me as error for
libraries\boost\boost\type_index\detail\compile_time_type_info.hpp ,  line 279
(" boost::typeindex::detail::failed_to_get_function_name();") :
no matching function for call to 'failed_to_get_function_name'



....and as info for \libraries\boost\boost\type_index\ctti_type_index.hpp , line
117 :
in instantiation of member function 'boost::detail::ctti<void>::n' requested
here

also info for libraries\boost\boost\type_index\detail\compile_time_type_info.hpp
, line 87 :
candidate template ignored: couldn't infer template argument 'T'

If I click to show definition of 'T', below are lines :
"TypeIndex library could not detect your compiler.Please make the
BOOST_TYPE_INDEX_FUNCTION_SIGNATURE macro use correct compiler macro for getting
the whole function name. Define BOOST_TYPE_INDEX_CTTI_USER_DEFINED_PARSING to
correct value after that."

I am using Visual Studio 2019 building Release x64 target, with LLVM as a
compiler, ISO standard Language version C++14, --disable-io-restrictions
-Wno-c++11-narrowing, and with all other changes mentioned before in this
discussion. any clue what else to change to keep/(start?) moving forward?

[Mr] Re: Hgpovray38, current state [1984 days 4 hours and 23 minutes ago]

Fri, 6 Nov 2020 11:45:00 GMT

"Mr" <nomail@nomail> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Le 24/10/2020 Ã  17:59, Le_Forgeron a Ã©critÂ :
> > > Le 23/10/2020 Ã  16:10, Mr a Ã©critÂ :
> > >> Le_Forgeron <jgr### [at] freefr> wrote:
> > >>> For the people who do not want to bother with git, Hgpovray is now
> > >>> available as sources
> > >>>
> > >>>
> > >>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
> > >>>
> > >>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
> > >>>
> > >>> More works on the agenda :
> > >>>
> > >>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> > >>
> > >> Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
> > >> background behind submarine instead of blue with current 3.8 plain pov master.
> > >>
> > >>
> > >
> > > Can you identify the version of hgpovray38 ?
> > >
> > Oups, my bad. 226 Thermidor is 2 years old.
> >
> > I will check with the latest head.
>
> Hi, I tried building on windows again with "betterave", and after reimplementing
> all the changes previously mentioned in this thread I manage to push again many
> of the errors away, but fail to see what to do about the wrong type line 485 of
> windows/pvengine.cpp :
> https://github.com/LeForgeron/povray/blob/Hgpovray/windows/pvengine.cpp#L485
>
> At the end of a struct array typed WORD, having -1 values maybe to specify end
> of array that looks like list of all keys that allow to scroll.
>
> It seems that some difference relied upon *outside* this file allows vanilla pov
> to build with that same technique.
>
>
> Is there maybe some library that I could change to more recent version? (I
> already pushed many errors by replacing boost folder... But maybe I want too far
> with that one in a too recent version?

Adding :
-Wno-c++11-narrowing

into additional compiler options seems to have solved that... next issues coming
soon :-)

[Mr] Re: Hgpovray38, current state [1984 days 7 hours and 53 minutes ago]

Fri, 6 Nov 2020 08:15:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 24/10/2020 Ã  17:59, Le_Forgeron a Ã©critÂ :
> > Le 23/10/2020 Ã  16:10, Mr a Ã©critÂ :
> >> Le_Forgeron <jgr### [at] freefr> wrote:
> >>> For the people who do not want to bother with git, Hgpovray is now
> >>> available as sources
> >>>
> >>>
> >>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
> >>>
> >>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
> >>>
> >>> More works on the agenda :
> >>>
> >>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> >>
> >> Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
> >> background behind submarine instead of blue with current 3.8 plain pov master.
> >>
> >>
> >
> > Can you identify the version of hgpovray38 ?
> >
> Oups, my bad. 226 Thermidor is 2 years old.
>
> I will check with the latest head.

Hi, I tried building on windows again with "betterave", and after reimplementing
all the changes previously mentioned in this thread I manage to push again many
of the errors away, but fail to see what to do about the wrong type line 485 of
windows/pvengine.cpp :
https://github.com/LeForgeron/povray/blob/Hgpovray/windows/pvengine.cpp#L485

At the end of a struct array typed WORD, having -1 values maybe to specify end
of array that looks like list of all keys that allow to scroll.

It seems that some difference relied upon *outside* this file allows vanilla pov
to build with that same technique.


Is there maybe some library that I could change to more recent version? (I
already pushed many errors by replacing boost folder... But maybe I want too far
with that one in a too recent version?

[William F Pokorny] Performance issue with preview and sdl2.0. [1989 days 2 hours and 12 minutes ago]

Sun, 1 Nov 2020 13:56:04 GMT

A notice for folks running hgpovray38 or povr.

On my Ubuntu 20.4.1 system just tripped on a significant performance 
issue with the preview feature when using the Simple DirectMedia Layer 
2.0 version. SDL2.0 the usual default, if the library is available when 
compiling.

You use the preview feature with radiosity always, but one can also set 
preview start and end (+sp32 +ep8) for non-radiosity renders.

No idea what's happening, but when timing with /usr/bin/time, what I see 
is a big jump in elapsed time. Using x11 or sdl1.2 on my current example 
render I get:

31.36user 0.14system 0:09.83elapsed

increasing to:

34.49user 4.54system 0:24.44elapsed

with sdl2.0. (+148%)

Bill P.

[Mr] Re: Hgpovray38, current state [1995 days 8 hours and 58 minutes ago]

Mon, 26 Oct 2020 07:10:01 GMT

"Mr" <nomail@nomail> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Latest package:
> >
> > https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.229.Betterave
> >
> > >
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.229.Betterave
>
> Thanks ! It does render with blue background now.
> Next issue is when I try to render the grenadine scene, I get a "Parse Error:
> Cannot open include file lemon.inc." (disregarding any +L option).
> That however could also happen with standard povray 3.8.

Sorry, ignore the grenadine (non)issue, I was making a typo.

[Mr] Re: Hgpovray38, current state [1995 days 9 hours and 28 minutes ago]

Mon, 26 Oct 2020 06:40:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Latest package:
>
> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.229.Betterave
>
> > https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.229.Betterave

Thanks ! It does render with blue background now.
Next issue is when I try to render the grenadine scene, I get a "Parse Error:
Cannot open include file lemon.inc." (disregarding any +L option).
That however could also happen with standard povray 3.8.

[Le Forgeron] Re: Hgpovray38, current state [1996 days 3 hours and 22 minutes ago]

Sun, 25 Oct 2020 12:45:43 GMT

Latest package:

https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.229.Betterave

> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.229.Betterave

[William F Pokorny] Re: Hgpovray38, current state [1996 days 4 hours and 3 minutes ago]

Sun, 25 Oct 2020 12:04:34 GMT

On 10/25/20 5:57 AM, Le_Forgeron wrote:
> Le 25/10/2020 Ã  10:33, Le_Forgeron a Ã©critÂ :
>> Le 25/10/2020 Ã  02:35, Bald Eagle a Ã©critÂ :
...
>>
>> Commenting the media in the last union, get the same bad result as
>> hgpovray38 with povray master 3.8;
>>

I'd not have looked if not for the claim of the same bad results in 
povray master 3.8, but I branched off the last commit to master and I do 
not see that line in tracepixel.cpp commented. (I've not run the test case)

If any help, I went on to look at the state of tracepixel.cpp for every 
commit since the move the github. I see twelve up to v3.8 master head 
and none have the precompute... line commented.

> 
> Ok, I can fix it... but I do not understand yet why it happened and how
> it works.
> 
> diff --git a/source/core/render/tracepixel.cpp
> b/source/core/render/tracepixel.cpp
> index 6d661b07..50d420a1 100644
> --- a/source/core/render/tracepixel.cpp
> +++ b/source/core/render/tracepixel.cpp
> @@ -235,7 +235,7 @@ void TracePixelCameraData::SetupCamera(const Camera&
> cam)
>       bool normalise = false;
>       camera = cam;
>       useFocalBlur = false;
> -    //precomputeContainingInteriors = true;
> +    precomputeContainingInteriors = true;
>       cameraDirection = camera.Direction;
>       cameraRight = camera.Right;
>       cameraUp =  camera.Up;
>

[Le Forgeron] Re: Hgpovray38, current state [1996 days 6 hours and 10 minutes ago]

Sun, 25 Oct 2020 09:57:40 GMT

Le 25/10/2020 Ã  10:33, Le_Forgeron a Ã©critÂ :
> Le 25/10/2020 Ã  02:35, Bald Eagle a Ã©critÂ :
>>
>> "Mr" <nomail@nomail> wrote:
>>
>>>> Ok, happens also with latest head. I will have to search when it
>>>> started, not fun as I did not play with media.
>>
>>> maybe color models are to be suspected as so many  relatively recent changes
>>> happened ?
>>> (rgb > srgb rgbf rgbt RAL...)
>>
>> Works ok in (qtpovray)3.8, using #version 3.6 and #version 3.8
>>
>> Line 786 has a negative light source, so maybe scroll down to that section and
>> start commenting out some lights and see what happens.
>>
> 
> Negative light are honored, not the problem.
> 
>> after that is // submarine and media
>>
>> light in lines Line 73 & 74 has media_interaction off
>>
>> Other than that - no idea.
>>
>>
> 
> Commenting the media in the last union, get the same bad result as
> hgpovray38 with povray master 3.8;
> 

Ok, I can fix it... but I do not understand yet why it happened and how
it works.

diff --git a/source/core/render/tracepixel.cpp
b/source/core/render/tracepixel.cpp
index 6d661b07..50d420a1 100644
--- a/source/core/render/tracepixel.cpp
+++ b/source/core/render/tracepixel.cpp
@@ -235,7 +235,7 @@ void TracePixelCameraData::SetupCamera(const Camera&
cam)
     bool normalise = false;
     camera = cam;
     useFocalBlur = false;
-    //precomputeContainingInteriors = true;
+    precomputeContainingInteriors = true;
     cameraDirection = camera.Direction;
     cameraRight = camera.Right;
     cameraUp =  camera.Up;

[Le Forgeron] Re: Hgpovray38, current state [1996 days 6 hours and 34 minutes ago]

Sun, 25 Oct 2020 09:33:26 GMT

Le 25/10/2020 Ã  02:35, Bald Eagle a Ã©critÂ :
> 
> "Mr" <nomail@nomail> wrote:
> 
>>> Ok, happens also with latest head. I will have to search when it
>>> started, not fun as I did not play with media.
> 
>> maybe color models are to be suspected as so many  relatively recent changes
>> happened ?
>> (rgb > srgb rgbf rgbt RAL...)
> 
> Works ok in (qtpovray)3.8, using #version 3.6 and #version 3.8
> 
> Line 786 has a negative light source, so maybe scroll down to that section and
> start commenting out some lights and see what happens.
> 

Negative light are honored, not the problem.

> after that is // submarine and media
> 
> light in lines Line 73 & 74 has media_interaction off
> 
> Other than that - no idea.
> 
> 

Commenting the media in the last union, get the same bad result as
hgpovray38 with povray master 3.8;

[Bald Eagle] Re: Hgpovray38, current state [1996 days 14 hours and 28 minutes ago]

Sun, 25 Oct 2020 01:40:01 GMT

"Mr" <nomail@nomail> wrote:

> > Ok, happens also with latest head. I will have to search when it
> > started, not fun as I did not play with media.

> maybe color models are to be suspected as so many  relatively recent changes
> happened ?
> (rgb > srgb rgbf rgbt RAL...)

Works ok in (qtpovray)3.8, using #version 3.6 and #version 3.8

Line 786 has a negative light source, so maybe scroll down to that section and
start commenting out some lights and see what happens.

after that is // submarine and media

light in lines Line 73 & 74 has media_interaction off

Other than that - no idea.

[Mr] Re: Hgpovray38, current state [1996 days 18 hours and 8 minutes ago]

Sat, 24 Oct 2020 22:00:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 24/10/2020 Ã  18:11, Le_Forgeron a Ã©critÂ :
> > Le 24/10/2020 Ã  17:59, Le_Forgeron a Ã©critÂ :
> >> Le 23/10/2020 Ã  16:10, Mr a Ã©critÂ :
> >>> Le_Forgeron <jgr### [at] freefr> wrote:
> >>>> For the people who do not want to bother with git, Hgpovray is now
> >>>> available as sources
> >>>>
> >>>>
> >>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
> >>>>
> >>>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
> >>>>
> >>>> More works on the agenda :
> >>>>
> >>>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> >>>
> >>> Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
> >>> background behind submarine instead of blue with current 3.8 plain pov master.
> >>>
> >>>
> >>
> >> Can you identify the version of hgpovray38 ?
> >>
> > Oups, my bad. 226 Thermidor is 2 years old.
> >
> > I will check with the latest head.
> >
>
> Ok, happens also with latest head. I will have to search when it
> started, not fun as I did not play with media.
maybe color models are to be suspected as so many  relatively recent changes
happened ?
(rgb > srgb rgbf rgbt RAL...)

[Le Forgeron] Re: Hgpovray38, current state [1996 days 23 hours and 41 minutes ago]

Sat, 24 Oct 2020 16:26:56 GMT

Le 24/10/2020 Ã  18:11, Le_Forgeron a Ã©critÂ :
> Le 24/10/2020 Ã  17:59, Le_Forgeron a Ã©critÂ :
>> Le 23/10/2020 Ã  16:10, Mr a Ã©critÂ :
>>> Le_Forgeron <jgr### [at] freefr> wrote:
>>>> For the people who do not want to bother with git, Hgpovray is now
>>>> available as sources
>>>>
>>>>
>>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>>>>
>>>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>>>>
>>>> More works on the agenda :
>>>>
>>>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>>
>>> Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
>>> background behind submarine instead of blue with current 3.8 plain pov master.
>>>
>>>
>>
>> Can you identify the version of hgpovray38 ?
>>
> Oups, my bad. 226 Thermidor is 2 years old.
> 
> I will check with the latest head.
> 

Ok, happens also with latest head. I will have to search when it
started, not fun as I did not play with media.

[Le Forgeron] Re: Hgpovray38, current state [1996 days 23 hours and 57 minutes ago]

Sat, 24 Oct 2020 16:11:10 GMT

Le 24/10/2020 Ã  17:59, Le_Forgeron a Ã©critÂ :
> Le 23/10/2020 Ã  16:10, Mr a Ã©critÂ :
>> Le_Forgeron <jgr### [at] freefr> wrote:
>>> For the people who do not want to bother with git, Hgpovray is now
>>> available as sources
>>>
>>>
>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>>>
>>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>>>
>>> More works on the agenda :
>>>
>>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>
>> Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
>> background behind submarine instead of blue with current 3.8 plain pov master.
>>
>>
> 
> Can you identify the version of hgpovray38 ?
> 
Oups, my bad. 226 Thermidor is 2 years old.

I will check with the latest head.

[Le Forgeron] Re: Hgpovray38, current state [1997 days and 8 minutes ago]

Sat, 24 Oct 2020 15:59:23 GMT

Le 23/10/2020 Ã  16:10, Mr a Ã©critÂ :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> For the people who do not want to bother with git, Hgpovray is now
>> available as sources
>>
>>
>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>>
>>>
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>>
>> More works on the agenda :
>>
>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> 
> Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
> background behind submarine instead of blue with current 3.8 plain pov master.
> 
> 

Can you identify the version of hgpovray38 ?

[Mr] Re: Hgpovray38, current state [1998 days 1 hour and 53 minutes ago]

Fri, 23 Oct 2020 14:15:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> For the people who do not want to bother with git, Hgpovray is now
> available as sources
>
>
> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>
> >
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30
>
> More works on the agenda :
>
> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38

Hello, ...With the set of default scenes, the advanced/abyss.pov shows a black
background behind submarine instead of blue with current 3.8 plain pov master.

[Mr] Re: Hgpovray38, current state [2017 days 1 hour and 18 minutes ago]

Sun, 4 Oct 2020 14:50:00 GMT

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

> My upfront guess is the windows libraries directory is out of date for
> the environment in which you are compiling. Give -std=c++11 a try. If
> you're lucky, let us know.
>
> Bill P.

Indeed, instead of what was in my last message, I just replaced the content of
boost immediate sub-directories with what was in the similarly named directories
of a fresh boost download... That got rid of this error! (I wonder if my two
previous modifications (posix ssize_t specific import and typedef, and cam
tokenizer pointer are still needed. I will assume they were and go on after
switching back to iso c++14 language version) I am left with another error line
506 in pvengine.cpp,
at the end of SCROLLKEYS key2scroll []:

constant expression evaluates to -1 which cannot be narrowed to type 'WORD' (aka
'unsigned short') [-Wc++11-narrowing] GUI
C:\HG-povray\povray-hgpovray38\windows\pvengine.cpp 506

I also have the exact same error for what appears (to my Python-only eye) to be
a negative index, line 223 in pvmisc.cpp

I don't know by what to replace them ?

[William F Pokorny] Re: Hgpovray38, current state [2017 days 2 hours and 18 minutes ago]

Sun, 4 Oct 2020 13:49:35 GMT

On 10/3/20 7:20 PM, Mr wrote:
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
...
> (using CLANG-cl compiler in MSVS2019 from its internal installer, and ISO C++ 17
> language version
> 

The code to which you are pointing is not familiar to me.

Have you tried compiling with the compiler flag '-std=c++11' ?

For windows compiles, the libraries necessary are in the libraries 
directory. In the official POV-Ray code base these have not been updated 
in a long time. Further, the POV-Ray base code is only ensured to work 
with c++11.

In what state you might find the libraries directory in hgpovray38 I do 
not know. Jerome was a Ubuntu user last I knew.

On unix/linux based systems the libraries are install-able based upon a 
release of whatever version of unix/linux/osx one runs. Therefore these 
libraries will work (are supposed to work) with the default c/c++ 
compiler version shipped. Compiles in the unix/linux/osx environments do 
not use the libraries directory.

The g++ default for Ubuntu 18.04.1 and 20.04.1 to which I just upgraded 
is c++14. I also set -std=c++11 occasionally to test I have not 
introduced something code wise which will not compile at that standard. 
In doing that for povr, I'm pretty sure POV-Ray itself still OK at c++11.

I've also played with compiles using -std=c++17, but these don't compile 
on 18.04 systems because the Ubuntu 18.04 'libraries' are not compatible 
with c++17(1). A hint the even older libraries directory versions likely 
are not.

(1) I've not yet tried a -stdc++17 compile on Ubuntu 20.04.1 - in part 
because I've been busy these past few days cleaning up new warnings in 
the povr code base I now see in the Ubuntu 20.04.1 environment!

My upfront guess is the windows libraries directory is out of date for 
the environment in which you are compiling. Give -std=c++11 a try. If 
you're lucky, let us know.

Bill P.

[jr] Re: Hgpovray38, current state [2017 days 7 hours and 18 minutes ago]

Sun, 4 Oct 2020 08:50:00 GMT

hi,

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > > "jr" <cre### [at] gmailcom> wrote:
> > > > > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > > > > ...  I can't afford to not be cross platform
> > > > > ...
> Hi, I went on trying:
> ...
> However in function _template.hpp, line 662 should also change:
>     , public std::function<T0,R>
> and line 666:
>     , public std::function<T0,T1,R>
> but to what?

uh, sorry, no idea, this is way into C++ territory.  hopefully JG, or someone
else with the required language skills, can help.


regards, jr.

[Mr] Re: Hgpovray38, current state [2017 days 16 hours and 43 minutes ago]

Sat, 3 Oct 2020 23:25:01 GMT

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > hi,
> >
> > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > "jr" <cre### [at] gmailcom> wrote:
> > > > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > > > ...  I can't afford to not be cross platform
> > > >
> > > > you know that POV-Ray builds, you know that Hg is derived from the same
sources.
> > > >  it would be a lot of work, but if you worked through the differences in the
> > > > sources, perhaps aided by single-stepping (with debugger) through POV-Ray
> > > > execution, you could (likely) find out exactly what
> > > > 'Get_Token_String(CYLINDER_TOKEN)' returns, and what else matters at that
point
> > > > in the code.  sorry to be of little/no help.
> > >
> > > I had tried but could not find 'Get_Token_String(CYLINDER_TOKEN)' used in the
> > > same context in POV-Ray trunk source, I may have searched wrong.
> > > Just trying to help would already be a lot! besides I do have the impression
> > > that you did unlock a few a step forwards. thanks !
> >
> > thanks for the .. vote of confidence.  (flattery will get you anywhere..  :-))
> >
> > I've created two 'tags' files with the symbols/names used in the sources.
> > searching them for 'Get_Token' gives me:
> >
> > jr@swift:1:tmp$ xzgrep -n Get_Token hg_tags.xz
> > 46500:Get_Token
> > povray-3.8.0.alpha-Hg.226.Bigarade/source/parser/parser_tokenizer.cpp 317;" f
> > class:pov_parser::Parser
> > 46501:Get_Token_String
> > povray-3.8.0.alpha-Hg.226.Bigarade/source/parser/parser_tokenizer.cpp 1701;" f
> > class:pov_parser::Parser
> > jr@swift:2:tmp$ xzgrep -n Get_Token pov_tags.xz
> > 45379:Get_Token povray-3.8.0-alpha.10064268/source/parser/parser_tokenizer.cpp
> > 210;" f class:pov_parser::Parser
> > 45380:Get_Token_String
> > povray-3.8.0-alpha.10064268/source/parser/parser_tokenizer.cpp 877;" f
> > class:pov_parser::Parser
> > jr@swift:3:tmp$
> >
> > you can download the listings from here:
> >
> >
<https://drive.google.com/file/d/10RaLHKnogRE6ikkiaybHMP4d8ezyZfH9/view?usp=sharing>
> >
<https://drive.google.com/file/d/10ThvgvOXlnSnHJrlAVdiV1UF1fcRpAIZ/view?usp=sharing>
> >
> > they're about 20M each, so I have used 'xz' to compress, you can use 'WinRAR' to
> > uncompress if you don't have an 'unxz' installed.
> >
> >
> > regards, jr.
> >
> > (reply via email if you feel this discussion is a bit off-topic)
>
>
> The solution from this page seems to bring me a step further:
>
https://stackoverflow.com/questions/33423502/expression-did-not-evaluate-to-a-constant-c
>
> so...
> char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
> becomes
> char* tmp_compound = new char[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
>

Hi, I went on trying:
....Then removing deprecated binary_function following this page helped me clear
the next issue:
https://stackoverflow.com/questions/22386882/why-have-unary-function-binary-function-been-removed-from-c11
So in compare_pointees.hpp line 36 may become:

struct equal_pointees_t {
  bool operator() ( OptionalPointee const& x, OptionalPointee const& y ) const
    { return equal_pointees(x,y) ; }
  typedef OptionalPointee first_argument_type;
  typedef OptionalPointee second_argument_type;
  typedef bool result_type;
} ;


And line 61:

struct less_pointees_t {
  bool operator() ( OptionalPointee const& x, OptionalPointee const& y ) const
    { return less_pointees(x,y) ; }
  typedef OptionalPointee first_argument_type;
  typedef OptionalPointee second_argument_type;
  typedef bool result_type;
} ;

However in function _template.hpp, line 662 should also change:
    , public std::function<T0,R>
and line 666:
    , public std::function<T0,T1,R>
but to what?


(using CLANG-cl compiler in MSVS2019 from its internal installer, and ISO C++ 17
language version

[Mr] Re: Hgpovray38, current state [2133 days 21 hours and 13 minutes ago]

Tue, 9 Jun 2020 18:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > > ...  I can't afford to not be cross platform
> > >
> > > you know that POV-Ray builds, you know that Hg is derived from the same sources.
> > >  it would be a lot of work, but if you worked through the differences in the
> > > sources, perhaps aided by single-stepping (with debugger) through POV-Ray
> > > execution, you could (likely) find out exactly what
> > > 'Get_Token_String(CYLINDER_TOKEN)' returns, and what else matters at that point
> > > in the code.  sorry to be of little/no help.
> >
> > I had tried but could not find 'Get_Token_String(CYLINDER_TOKEN)' used in the
> > same context in POV-Ray trunk source, I may have searched wrong.
> > Just trying to help would already be a lot! besides I do have the impression
> > that you did unlock a few a step forwards. thanks !
>
> thanks for the .. vote of confidence.  (flattery will get you anywhere..  :-))
>
> I've created two 'tags' files with the symbols/names used in the sources.
> searching them for 'Get_Token' gives me:
>
> jr@swift:1:tmp$ xzgrep -n Get_Token hg_tags.xz
> 46500:Get_Token
> povray-3.8.0.alpha-Hg.226.Bigarade/source/parser/parser_tokenizer.cpp 317;" f
> class:pov_parser::Parser
> 46501:Get_Token_String
> povray-3.8.0.alpha-Hg.226.Bigarade/source/parser/parser_tokenizer.cpp 1701;" f
> class:pov_parser::Parser
> jr@swift:2:tmp$ xzgrep -n Get_Token pov_tags.xz
> 45379:Get_Token povray-3.8.0-alpha.10064268/source/parser/parser_tokenizer.cpp
> 210;" f class:pov_parser::Parser
> 45380:Get_Token_String
> povray-3.8.0-alpha.10064268/source/parser/parser_tokenizer.cpp 877;" f
> class:pov_parser::Parser
> jr@swift:3:tmp$
>
> you can download the listings from here:
>
> <https://drive.google.com/file/d/10RaLHKnogRE6ikkiaybHMP4d8ezyZfH9/view?usp=sharing>
> <https://drive.google.com/file/d/10ThvgvOXlnSnHJrlAVdiV1UF1fcRpAIZ/view?usp=sharing>
>
> they're about 20M each, so I have used 'xz' to compress, you can use 'WinRAR' to
> uncompress if you don't have an 'unxz' installed.
>
>
> regards, jr.
>
> (reply via email if you feel this discussion is a bit off-topic)


The solution from this page seems to bring me a step further:
https://stackoverflow.com/questions/33423502/expression-did-not-evaluate-to-a-constant-c

so...
char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
becomes
char* tmp_compound = new char[4+strlen(Get_Token_String(CYLINDER_TOKEN))];

Now I'm left with new lnk errors of "unresolved external symbols"(?) in
povcore64d.lib(tracepixel.obj)

[jr] Re: Hgpovray38, current state [2138 days 7 hours and 53 minutes ago]

Fri, 5 Jun 2020 08:15:00 GMT

hi,

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > ...  I can't afford to not be cross platform
> >
> > you know that POV-Ray builds, you know that Hg is derived from the same sources.
> >  it would be a lot of work, but if you worked through the differences in the
> > sources, perhaps aided by single-stepping (with debugger) through POV-Ray
> > execution, you could (likely) find out exactly what
> > 'Get_Token_String(CYLINDER_TOKEN)' returns, and what else matters at that point
> > in the code.  sorry to be of little/no help.
>
> I had tried but could not find 'Get_Token_String(CYLINDER_TOKEN)' used in the
> same context in POV-Ray trunk source, I may have searched wrong.
> Just trying to help would already be a lot! besides I do have the impression
> that you did unlock a few a step forwards. thanks !

thanks for the .. vote of confidence.  (flattery will get you anywhere..  :-))

I've created two 'tags' files with the symbols/names used in the sources.
searching them for 'Get_Token' gives me:

jr@swift:1:tmp$ xzgrep -n Get_Token hg_tags.xz
46500:Get_Token
povray-3.8.0.alpha-Hg.226.Bigarade/source/parser/parser_tokenizer.cpp 317;" f
class:pov_parser::Parser
46501:Get_Token_String
povray-3.8.0.alpha-Hg.226.Bigarade/source/parser/parser_tokenizer.cpp 1701;" f
class:pov_parser::Parser
jr@swift:2:tmp$ xzgrep -n Get_Token pov_tags.xz
45379:Get_Token povray-3.8.0-alpha.10064268/source/parser/parser_tokenizer.cpp
210;" f class:pov_parser::Parser
45380:Get_Token_String
povray-3.8.0-alpha.10064268/source/parser/parser_tokenizer.cpp 877;" f
class:pov_parser::Parser
jr@swift:3:tmp$

you can download the listings from here:

<https://drive.google.com/file/d/10RaLHKnogRE6ikkiaybHMP4d8ezyZfH9/view?usp=sharing>
<https://drive.google.com/file/d/10ThvgvOXlnSnHJrlAVdiV1UF1fcRpAIZ/view?usp=sharing>

they're about 20M each, so I have used 'xz' to compress, you can use 'WinRAR' to
uncompress if you don't have an 'unxz' installed.


regards, jr.

(reply via email if you feel this discussion is a bit off-topic)

[Mr] Re: Hgpovray38, current state [2138 days 17 hours and 13 minutes ago]

Thu, 4 Jun 2020 22:55:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > ...  I can't afford to not be cross platform
>
> you know that POV-Ray builds, you know that Hg is derived from the same sources.
>  it would be a lot of work, but if you worked through the differences in the
> sources, perhaps aided by single-stepping (with debugger) through POV-Ray
> execution, you could (likely) find out exactly what
> 'Get_Token_String(CYLINDER_TOKEN)' returns, and what else matters at that point
> in the code.  sorry to be of little/no help.
>
>
> regards, jr.

I had tried but could not find 'Get_Token_String(CYLINDER_TOKEN)' used in the
same context in POV-Ray trunk source, I may have searched wrong.
Just trying to help would already be a lot! besides I do have the impression
that you did unlock a few a step forwards. thanks !

[jr] Re: Hgpovray38, current state [2139 days 1 hour and 43 minutes ago]

Thu, 4 Jun 2020 14:25:00 GMT

hi,

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> ...  I can't afford to not be cross platform

you know that POV-Ray builds, you know that Hg is derived from the same sources.
 it would be a lot of work, but if you worked through the differences in the
sources, perhaps aided by single-stepping (with debugger) through POV-Ray
execution, you could (likely) find out exactly what
'Get_Token_String(CYLINDER_TOKEN)' returns, and what else matters at that point
in the code.  sorry to be of little/no help.


regards, jr.

[Mr] Re: Hgpovray38, current state [2139 days 2 hours and 43 minutes ago]

Thu, 4 Jun 2020 13:25:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > one hack-ish workaround could be to separate out the operations, ie in C I might
> > > do something like:
> > >
> > > size_t const n = strlen(Get_Token_String(...));
> > > char tmp_compound[4 + n] = {'\0'};
> >
> > So instead of this:
> > char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
> >
> > ....and after adding the same include in parser_strings.cpp, I used:
> >
> > const ssize_t n = strlen(Get_Token_String(CYLINDER_TOKEN));
> > char tmp_compound[4 + n];
> >
> > And still error messages from the same line not eval to const also tried with
> > const int n = strlen(Get_Token_String(CYLINDER_TOKEN));
>
> two points.  the 'strlen()' function returns a 'size_t', that is, an unsigned
> value, while both 'int' and 'ssize_t' hold signed values; however, if that was
> the problem you would have seen "warning: conversion to..." messages, not
> errors.
>
> second, I just downloaded 'Hg.226.Bigarade' and built it; one single warning
> message aside, the program builds cleanly (on a Slackware GNU/Linux box).  so,
> sorry, cannot help any further, but my advice is: either create a virtual
> machine running a Linux, or install 'cygwin'[*], or explore whether the Windows
> 10/Ubuntu thing works for you.
>
> (I read the following quote in someone's signature block years back
> (paraphrased): "computers are like air-conditioning, they stop working when you
> open Windows."  ;-))
>
> [*] there are other s/wares too, like 'MinGW'.
>
>
> regards, jr

Sorry since my purpose is blender exporter use.  I can't afford to not be cross
platform

[jr] Re: Hgpovray38, current state [2139 days 7 hours and 13 minutes ago]

Thu, 4 Jun 2020 08:55:00 GMT

hi,

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > one hack-ish workaround could be to separate out the operations, ie in C I might
> > do something like:
> >
> > size_t const n = strlen(Get_Token_String(...));
> > char tmp_compound[4 + n] = {'\0'};
>
> So instead of this:
> char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
>
> ....and after adding the same include in parser_strings.cpp, I used:
>
> const ssize_t n = strlen(Get_Token_String(CYLINDER_TOKEN));
> char tmp_compound[4 + n];
>
> And still error messages from the same line not eval to const also tried with
> const int n = strlen(Get_Token_String(CYLINDER_TOKEN));

two points.  the 'strlen()' function returns a 'size_t', that is, an unsigned
value, while both 'int' and 'ssize_t' hold signed values; however, if that was
the problem you would have seen "warning: conversion to..." messages, not
errors.

second, I just downloaded 'Hg.226.Bigarade' and built it; one single warning
message aside, the program builds cleanly (on a Slackware GNU/Linux box).  so,
sorry, cannot help any further, but my advice is: either create a virtual
machine running a Linux, or install 'cygwin'[*], or explore whether the Windows
10/Ubuntu thing works for you.

(I read the following quote in someone's signature block years back
(paraphrased): "computers are like air-conditioning, they stop working when you
open Windows."  ;-))

[*] there are other s/wares too, like 'MinGW'.

regards, jr.

[Mr] Re: Hgpovray38, current state [2139 days 18 hours and 23 minutes ago]

Wed, 3 Jun 2020 21:45:03 GMT

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

> one hack-ish workaround could be to separate out the operations, ie in C I might
> do something like:
>
> size_t const n = strlen(Get_Token_String(...));
> char tmp_compound[4 + n] = {'\0'};

So instead of this:
char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];

....and after adding the same include in parser_strings.cpp, I used:

const ssize_t n = strlen(Get_Token_String(CYLINDER_TOKEN));
char tmp_compound[4 + n];

And still error messages from the same line not eval to const also tried with
const int n = strlen(Get_Token_String(CYLINDER_TOKEN));

[jr] Re: Hgpovray38, current state [2140 days and 43 minutes ago]

Wed, 3 Jun 2020 15:25:00 GMT

hi,
"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > ...
> > > > > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
> > > ...
> > > > you can fix the ssize_t error by defining it as a signed integer such as
> > > > int_least32_t
> > >
> > > I don't know if that was any sensible thing to do but, in parser.cpp, line 12022
> > > and 12023 I made a few attempts at replacing "ssize_t"
> > >
> > > ssize_t idx1 = std::min(Local_Vector[0], Local_Vector[1]);
> > > ssize_t idx2 = std::max(Local_Vector[0], Local_Vector[1]);
> > >
> > > First by "int_least32_t" and then by "unsigned int" and finally "int_least64_t",
> > > but every time only got an  error "conversion de 'size_t' en 'int', perte
> > > possible de données" and no build. Using MSVS 2015 on Windows 7, with I7
> > > processor machine.
> > >
> > > Any further advice?
> >
> > taking that error (from clean source, I assume) means that, for some reason, no
> > header is included which provides 'ssize_t'.  after a quick look on my system, I
> > think including 'unistd.h' would do.  alternatively, you could, at the top of
> > whichever .cpp file, add a definition (ideally with a '#ifndef' guard) like:
> >   #define ssize_t int
> >
> > POSIX guarantees a max of 32767, I think.
>
> Thanks
> I tried all manners of include suggested to no success... However, this seemed
> to do it for me, added after line 47 of parser.cpp below #include <algorithm> :
>
> #if defined(_MSC_VER)
> #include <BaseTsd.h>
> typedef SSIZE_T ssize_t;
> #endif

I had not realised you're on Redmond's finest.

I wonder whether using either the Linux "sub-system" supplied with Windows 10,
aiui, or an installation of 'cygwin', would not make all these errors/problems
go away.

<https://www.cygwin.com/>

> Now I have another error, Which I boldly assume unrelated:
> line 479  expression not evaluated to constant:
> char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];

one hack-ish workaround could be to separate out the operations, ie in C I might
do something like:

size_t const n = strlen(Get_Token_String(...));
char tmp_compound[4 + n] = {'\0'};

> as well as "Impossible d'utiliser 'this' dans une expression constante" (for the
> same line)
>
> web search brings me here:
>
https://docs.microsoft.com/fr-fr/cpp/error-messages/compiler-errors-1/compiler-error-c2131?view=vs-2019
>
> I interpret it as an incentive to initialize some variable or iterator index
> beforehand? I am standing still in the dark waiting for your lights !

some "lights", more like a 15W bulb.  :-)  good luck.


regards, jr.

[Mr] Re: Hgpovray38, current state [2140 days 2 hours and 3 minutes ago]

Wed, 3 Jun 2020 14:05:01 GMT

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:

> Now I have another error, Which I boldly assume unrelated:
> line 479  expression not evaluated to constant:
> char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
> as well as "Impossible d'utiliser 'this' dans une expression constante" (for the
> same line)
>
> web search brings me here:
>
https://docs.microsoft.com/fr-fr/cpp/error-messages/compiler-errors-1/compiler-error-c2131?view=vs-2019
>
> I interpret it as an incentive to initialize some variable or iterator index
> beforehand? I am standing still in the dark waiting for your lights !

I forgot to mention that this line 479 was now in parser_strings.cpp

[Mr] Re: Hgpovray38, current state [2140 days 2 hours and 18 minutes ago]

Wed, 3 Jun 2020 13:50:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > ...
> > > > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
> > ...
> > > you can fix the ssize_t error by defining it as a signed integer such as
> > > int_least32_t
> >
> > I don't know if that was any sensible thing to do but, in parser.cpp, line 12022
> > and 12023 I made a few attempts at replacing "ssize_t"
> >
> > ssize_t idx1 = std::min(Local_Vector[0], Local_Vector[1]);
> > ssize_t idx2 = std::max(Local_Vector[0], Local_Vector[1]);
> >
> > First by "int_least32_t" and then by "unsigned int" and finally "int_least64_t",
> > but every time only got an  error "conversion de 'size_t' en 'int', perte
> > possible de données" and no build. Using MSVS 2015 on Windows 7, with I7
> > processor machine.
> >
> > Any further advice?
>
> taking that error (from clean source, I assume) means that, for some reason, no
> header is included which provides 'ssize_t'.  after a quick look on my system, I
> think including 'unistd.h' would do.  alternatively, you could, at the top of
> whichever .cpp file, add a definition (ideally with a '#ifndef' guard) like:
>   #define ssize_t int
>
> POSIX guarantees a max of 32767, I think.
>
> hth.
>
>
>
> regards, jr.

Thanks
I tried all manners of include suggested to no success... However, this seemed
to do it for me, added after line 47 of parser.cpp below #include <algorithm> :


#if defined(_MSC_VER)
#include <BaseTsd.h>
typedef SSIZE_T ssize_t;
#endif


Now I have another error, Which I boldly assume unrelated:
line 479  expression not evaluated to constant:
char tmp_compound[4+strlen(Get_Token_String(CYLINDER_TOKEN))];
as well as "Impossible d'utiliser 'this' dans une expression constante" (for the
same line)

web search brings me here:
https://docs.microsoft.com/fr-fr/cpp/error-messages/compiler-errors-1/compiler-error-c2131?view=vs-2019

I interpret it as an incentive to initialize some variable or iterator index
beforehand? I am standing still in the dark waiting for your lights !

[jr] Re: Hgpovray38, current state [2140 days 21 hours and 13 minutes ago]

Tue, 2 Jun 2020 18:55:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> jr@crow:2:tmp$ cat mr.c
> #include <stdio.h>
> int main(void) {
>   ssize_t a, b, c;
>   a = -1, b = 0, c = 1;
>   printf("ssize_t vals: %zd  %zd  %zd\n", a, b, c);
>   return 0;
> }
> ...

and, although I don't "speak" C++, I was able to confirm that it should work if
you include 'stdio.h'.

jr@crow:6:tmp$ c### [at] mrcpp
#include <iostream>
#include <stdio.h>

int main(void) {
  ssize_t a, b, c;
  a = -1, b = 0, c = 1;
  std::cout << "ssize_t vals:" << a << "  " << b << "  " << c << "\n";
  return 0;
}

jr@crow:7:tmp$ c++ mr.cpp
jr@crow:8:tmp$ ./a.out
ssize_t vals:-1  0  1
jr@crow:9:tmp$


regards, jr.

[jr] Re: Hgpovray38, current state [2140 days 21 hours and 53 minutes ago]

Tue, 2 Jun 2020 18:15:00 GMT

hi,

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > > ...
> > > > > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
> > > ...
> > > > you can fix the ssize_t error by defining it as a signed integer such as
> > > > int_least32_t
> > >
> > > I don't know if that was any sensible thing to do but, in parser.cpp, line 12022
> > > and 12023 I made a few attempts at replacing "ssize_t"
> > >
> > > ssize_t idx1 = std::min(Local_Vector[0], Local_Vector[1]);
> > > ssize_t idx2 = std::max(Local_Vector[0], Local_Vector[1]);
> > >
> > > First by "int_least32_t" and then by "unsigned int" and finally "int_least64_t",
> > > but every time only got an  error "conversion de 'size_t' en 'int', perte
> > > possible de données" and no build. Using MSVS 2015 on Windows 7, with I7
> > > processor machine.
> > >
> > > Any further advice?
> >
> > taking that error (from clean source, I assume) means that, for some reason, no
> > header is included which provides 'ssize_t'.  after a quick look on my system, I
> > think including 'unistd.h' would do.  alternatively, you could, at the top of
> > whichever .cpp file, add a definition (ideally with a '#ifndef' guard) like:
> >   #define ssize_t int
> >
> > POSIX guarantees a max of 32767, I think.

should have written: guarantees at least a maximum of 32767.

> >
> I made a search for "unistd.h" and could not find it neither in HG-POV nor in
> POV-Ray 3.8 sources. what path should I include from? I tried without path and
> it is not found.


it's not part of an application, it's a system header (well, it is here, on a
Slackware GNU/Linux box).  turns out on my box just including 'stdio.h' is
enough.

jr@crow:1:tmp$ locate unistd.h | grep /usr/include
/usr/include/unistd.h
/usr/include/sys/unistd.h
/usr/include/asm-x86/unistd.h
/usr/include/bits/unistd.h
/usr/include/linux/unistd.h
/usr/include/asm-generic/unistd.h
jr@crow:2:tmp$ cat mr.c
#include <stdio.h>

int main(void) {
  ssize_t a, b, c;
  a = -1, b = 0, c = 1;
  printf("ssize_t vals: %zd  %zd  %zd\n", a, b, c);
  return 0;
}

jr@crow:3:tmp$ c99 mr.c
jr@crow:4:tmp$ ./a.out
ssize_t vals: -1  0  1
jr@crow:5:tmp$


(the 'c99' is a shell alias for the compiler)


regards, jr.

[Mr] Re: Hgpovray38, current state [2140 days 22 hours and 18 minutes ago]

Tue, 2 Jun 2020 17:50:00 GMT

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> > ...
> > > > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
> > ...
> > > you can fix the ssize_t error by defining it as a signed integer such as
> > > int_least32_t
> >
> > I don't know if that was any sensible thing to do but, in parser.cpp, line 12022
> > and 12023 I made a few attempts at replacing "ssize_t"
> >
> > ssize_t idx1 = std::min(Local_Vector[0], Local_Vector[1]);
> > ssize_t idx2 = std::max(Local_Vector[0], Local_Vector[1]);
> >
> > First by "int_least32_t" and then by "unsigned int" and finally "int_least64_t",
> > but every time only got an  error "conversion de 'size_t' en 'int', perte
> > possible de données" and no build. Using MSVS 2015 on Windows 7, with I7
> > processor machine.
> >
> > Any further advice?
>
> taking that error (from clean source, I assume) means that, for some reason, no
> header is included which provides 'ssize_t'.  after a quick look on my system, I
> think including 'unistd.h' would do.  alternatively, you could, at the top of
> whichever .cpp file, add a definition (ideally with a '#ifndef' guard) like:
>   #define ssize_t int
>
> POSIX guarantees a max of 32767, I think.
>
> hth.
>
>
>
> regards, jr.

I made a search for "unistd.h" and could not find it neither in HG-POV nor in
POV-Ray 3.8 sources. what path should I include from? I tried without path and
it is not found.

[jr] Re: Hgpovray38, current state [2141 days 1 hour and 38 minutes ago]

Tue, 2 Jun 2020 14:30:00 GMT

hi,

"Mr" <mauriceraybaud [at] hotmail dot fr>> wrote:
> ...
> > > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
> ...
> > you can fix the ssize_t error by defining it as a signed integer such as
> > int_least32_t
>
> I don't know if that was any sensible thing to do but, in parser.cpp, line 12022
> and 12023 I made a few attempts at replacing "ssize_t"
>
> ssize_t idx1 = std::min(Local_Vector[0], Local_Vector[1]);
> ssize_t idx2 = std::max(Local_Vector[0], Local_Vector[1]);
>
> First by "int_least32_t" and then by "unsigned int" and finally "int_least64_t",
> but every time only got an  error "conversion de 'size_t' en 'int', perte
> possible de données" and no build. Using MSVS 2015 on Windows 7, with I7
> processor machine.
>
> Any further advice?

taking that error (from clean source, I assume) means that, for some reason, no
header is included which provides 'ssize_t'.  after a quick look on my system, I
think including 'unistd.h' would do.  alternatively, you could, at the top of
whichever .cpp file, add a definition (ideally with a '#ifndef' guard) like:
  #define ssize_t int

POSIX guarantees a max of 32767, I think.

hth.

regards, jr.

[Mr] Re: Hgpovray38, current state [2141 days 6 hours and 53 minutes ago]

Tue, 2 Jun 2020 09:15:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 09/05/2020 Ã  14:49, Mr a Ã©critÂ :
> > Le_Forgeron <jgr### [at] freefr> wrote:
> >> Le 18/08/2018 ÃƒÂ  13:58, Le_Forgeron a
ÃƒÂ©critÃ‚Â :
> >>> For the people who do not want to bother with git, Hgpovray is now
> >>> available as sources
> >>>
> >>>
> >> Latest version so far:
> >>
> >> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
> >>
> >>> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
> >>
> >>
> >>> More works on the agenda :
> >>>
> >>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> >>>
> >
> > Bonjour !
> >
> > I just tried to build the latest HG-Pov I could find which seems to be that
> > Bigarade, right? Using MS VS2015,
> > Here is VS2015 build output:
> >
> > 1>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : vfewin, ConfigurationÂ : Debug x64
> > ------
> > 2>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : rtrsupport, ConfigurationÂ : Debug x64
> > ------
> > 3>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povbackend, ConfigurationÂ : Debug x64
> > ------
> > 4>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povbase, ConfigurationÂ : Debug x64
> > ------
> > 5>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povfrontend, ConfigurationÂ : Debug
> > x64 ------
> > 6>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : boost_date_time, ConfigurationÂ : Debug
> > x64 ------
> > 6>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette configuration
> > de solution
> > 7>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povcore, ConfigurationÂ : Debug x64
> > ------
> > 8>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povparser, ConfigurationÂ : Debug x64
> > ------
> > 1>  vfesession.cpp
> > 2>  vidcapimpl.cpp
> > 3>  boundingtask.cpp
> > 5>  povmain.cpp
> > 4>  colour.cpp
> > 7>  bounding.cpp
> > 8>  parser.cpp
> > 7>  texture.cpp
> > 4>  metadata.cpp
> > 3>..\..\source\backend\bounding\boundingtask.cpp(91): warning C4267:
'return'Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(162): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(163): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(178): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(179): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>  povray.cpp
> > 7>  scenedata.cpp
> > 5>povmain.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 5>  povfrontend.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povfrontend64d.lib
> > 3>..\..\source\backend\povray.cpp(515): warning C4267: 'argument'Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 3>  benchmark.cpp
> > 3>  renderbackend.cpp
> > 7>  tracethreaddata.cpp
> > 8>..\..\source\parser\parser.cpp(9673): warning C4267: 'argument'Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12022): error C2146: erreur de
syntaxeÂ :
> > absence de ';' avant l'identificateur 'idx1'
> > 4>  mathutil.cpp
> > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'idx1'Â :
identificateur
> > non dÃ©clarÃ©
> > 4>  GÃ©nÃ©ration de code en cours...
> > 8>..\..\source\parser\parser.cpp(12023): error C2065: 'ssize_t'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12023): error C2146: erreur de
syntaxeÂ :
> > absence de ';' avant l'identificateur 'idx2'
> > 8>..\..\source\parser\parser.cpp(12023): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx1'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12026): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12028): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx1'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 4>  jpeg.cpp
> > 8>  parser_strings.cpp
> > 7>  box.cpp
> > 3>  scene.cpp
> > 7>  GÃ©nÃ©ration de code en cours...
> > 4>..\..\source\base\image\jpeg.cpp(502): warning C4267: 'argument'Â :
conversion
> > de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 8>..\..\source\parser\parser_strings.cpp(479): error C2131: l'expression n'a pas
> > Ã©tÃ© Ã©valuÃ©e en constante
> > 8>  ..\..\source\parser\parser_strings.cpp(479): note: Ã©chec en raison
> > d'arguments non constants ou d'une rÃ©fÃ©rence Ã  un
symbole non constant
> > 8>  ..\..\source\parser\parser_strings.cpp(479): note: voir l'utilisation de
> > 'this'
> > 8>..\..\source\parser\parser_strings.cpp(708): warning C4267: '='Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>..\..\source\parser\parser_strings.cpp(1176): warning C4267: '='Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>  parser_tokenizer.cpp
> > 3>  GÃ©nÃ©ration de code en cours...
> > 8>..\..\source\parser\parser_tokenizer.cpp(1514): warning C4267: '='Â :
> > conversion de 'size_t' en 'int', perte possible de donnÃ©es
> > 7>bounding.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 4>  png.cpp
> > 8>..\..\source\parser\parser_tokenizer.cpp(3915): warning C4267: '='Â :
> > conversion de 'size_t' en 'int', perte possible de donnÃ©es
> > 2>  vidcap.cpp
> > 8>..\..\source\parser\parser_tokenizer.cpp(3935): warning C4267: '='Â :
> > conversion de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>  GÃ©nÃ©ration de code en cours...
> > 3>  povbackend.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbackend64d.lib
> > 7>  povcore.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povcore64d.lib
> > 4>  GÃ©nÃ©ration de code en cours...
> > 4>timer.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 4>mathutil.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 4>  povbase.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbase64d.lib
> > 2>  rtrsupport.cpp
> > 1>  vfewin.vcxproj ->
> > C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\vfe64d.lib
> > 2>  GÃ©nÃ©ration de code en cours...
> > 2>vidcap.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 2>  rtrsupport.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\rtrsupport64d.lib
> > 9>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : tests, ConfigurationÂ : Debug x64 ------
> > 9>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette configuration
> > de solution
> > 10>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : GUI, ConfigurationÂ : Debug x64
> > ------
> > 11>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : console, ConfigurationÂ : Debug x64
> > ------
> > 11>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette
> > configuration de solution
> > 10>  pvbitmap.cpp
> > 10>  pvdialog.cpp
> > 10>  pvdisplay.cpp
> > 10>  pvedit.cpp
> > 10>..\pvedit.cpp(301): warning C4267: '+='Â : conversion de 'size_t' en
'int',
> > perte possible de donnÃ©es
> > 10>  pvengine.cpp
> > 10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(1544): warning
> > C4091: 'typedef 'Â : ignorÃ© Ã  gauche de '' quand
aucune variable n'est dÃ©clarÃ©e
> > 10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(3190): warning
> > C4091: 'typedef 'Â : ignorÃ© Ã  gauche de '' quand
aucune variable n'est dÃ©clarÃ©e
> > 10>..\pvengine.cpp(498): warning C4838: la conversion de 'int' en 'WORD'
> > requiert une conversion restrictive
> > 10>..\pvengine.cpp(1721): warning C4477: 'sprintf'Â : la
chaÃ®ne de format '%p'
> > nÃ©cessite un argument de type 'void *', mais l'argument variadique 2
est de type
> > 'DWORD64'
> > 10>..\pvengine.cpp(5152): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> > dÃ©conseillÃ©
> > 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> > voir la dÃ©claration de 'GetVersionExA'
> > 10>..\pvengine.cpp(5608): warning C4267: '='Â : conversion de 'size_t'
en
> > 'unsigned int', perte possible de donnÃ©es
> > 10>..\pvengine.cpp(5787): warning C4267: '='Â : conversion de 'size_t'
en
> > 'unsigned int', perte possible de donnÃ©es
> > 10>..\pvengine.cpp(5719): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> > dÃ©conseillÃ©
> > 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> > voir la dÃ©claration de 'GetVersionExA'
> > 10>  pvfiles.cpp
> > 10>  pvfrontend.cpp
> > 10>  pvguiext.cpp
> > 10>  pvmem.cpp
> > 10>  pvmenu.cpp
> > 10>  pvmisc.cpp
> > 10>..\pvmisc.cpp(223): warning C4838: la conversion de 'int' en 'unsigned int'
> > requiert une conversion restrictive
> > 10>  pvtext.cpp
> > 10>  pvupdate.cpp
> > 10>..\pvupdate.cpp(166): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> > dÃ©conseillÃ©
> > 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> > voir la dÃ©claration de 'GetVersionExA'
> > 10>  GÃ©nÃ©ration de code en cours...
> > 10>LINK : fatal error LNK1104: impossible d'ouvrir le fichier
> >
'C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povparser64d.lib'
> > ========== GÃ©nÃ©rationÂ : 6 a rÃ©ussi, 2
a Ã©chouÃ©, 15 mis Ã  jour, 3 a
Ã©tÃ© ignorÃ©
> > ==========
> >
> >
> >
> >
>
> you can fix the ssize_t error by defining it as a signed integer such as
> int_least32_t

I don't know if that was any sensible thing to do but, in parser.cpp, line 12022
and 12023 I made a few attempts at replacing "ssize_t"

ssize_t idx1 = std::min(Local_Vector[0], Local_Vector[1]);
ssize_t idx2 = std::max(Local_Vector[0], Local_Vector[1]);


First by "int_least32_t" and then by "unsigned int" and finally "int_least64_t",
but every time only got an  error "conversion de 'size_t' en 'int', perte
possible de données" and no build. Using MSVS 2015 on Windows 7, with I7
processor machine.

Any further advice?

[Mr] Re: Blurred reflections [2163 days 7 hours and 23 minutes ago]

Mon, 11 May 2020 08:45:01 GMT

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2020-05-09 4:29 PM (-4), Mr wrote:
> > "And" <49341109@ntnu.edu.tw> wrote:
> >> Will blurred reflection integrate into official version one day? (this function
> >> is too important)
> > Things did evolve in the last two years. Now that Anti Aliasing method 3 is in
> > the main POV-Ray trunk, the said "framework" is there. The syntax... almost as
> > well, with things like the finish level fresnel paving the way to a similar
> > approach for roughness maybe. My question is, since then, did any other branch
> > than Uberpov also try to add this feature?
>
> The knowledge base alludes to MegaPOV having some blurred reflection
> capability, though I cannot find it in the MegaPOV documentation.  But
> MegaPOV development terminated long before UberPOV was released.
>
> Since development of UberPOV has wound down, I've found myself reverting
> to RC3Metal from the Object Collection, which works with standard
> POV-Ray.  What seems to work best for me with RC3Metal is to do a bunch
> of EXR renders with different seeds in an animation loop, then read them
> back as image maps and average them in a pigment_map.  To save time, I
> save the photons for the first 3 to 5 frames, then reuse them round
> robin for the remaining frames.  If there are no mutually reflecting
> surfaces, I just use a single render with a high sample count.
>
> Overall, UberPOV does a better job than RC3Metal, though, especially
> with specular highlights.

Hi Cousin Ricky
I had noticed your work on RC3Metal and also on sun & sky atmosphere, the
blender exporter could benefit a lot from your experiments!
However for the current issue, since exporter is already using Blender frames to
export a clock animation, I assume using clock for something else will add to
the already unreadable code. Also it already exports the possibility of a user's
bump_map, so micronormals have to combine with it, and also with the finish map
trick used to emulate a specular map.

For now I started testing a single "micro bump" layer averaged with the user
bump map and it kind of works better than I remembered, when I initially chose
Uberpov. Maybe I'm forgetting a use case that made me throw it away initially...

My latest attempt totally lost the user specular map visibility as it's kind of
eaten away by the micro bump... Next try, I should make it so that the one entry
with minimal specular also doesn't carry the microbump So the finish map trick
becomes a finish&bump_map metamap trick...

In the averaged normal_map I used 0.5 as the microbump entry value and same for
the user bump map.

I don't know if it  will break when I add another layer with different seed of
microbump to the average in the same clockframe. then I would probably state
0.25 for each micro bump layer and 0.5 for user bump texture,... with microbump
muted in less specular areas(?), roughly speaking:

texture{
        pigment_pattern {
            uv_mapping image_map{jpeg "PATH\\TO\\UserSpecularMap.jpg" map_type 0
}
        }
        texture_map {
            [0
                pigment {rgbft<0.8, 0.8, 0.8, 0, 0>}
                finish {finish_WITH_MIN_SPEC}
                normal {user Bump_map only}
            ]
            [1
                pigment {rgbft<0.8, 0.8, 0.8, 0, 0>}
                finish {finish_WITH_MAX_SPEC}
                normal {average of microbump(s) and user bump_map}
            ]
        }
    }

[Cousin Ricky] Re: Blurred reflections [2164 days and 44 minutes ago]

Sun, 10 May 2020 15:24:13 GMT

On 2020-05-09 4:29 PM (-4), Mr wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>> Will blurred reflection integrate into official version one day? (this function
>> is too important)
> Things did evolve in the last two years. Now that Anti Aliasing method 3 is in
> the main POV-Ray trunk, the said "framework" is there. The syntax... almost as
> well, with things like the finish level fresnel paving the way to a similar
> approach for roughness maybe. My question is, since then, did any other branch
> than Uberpov also try to add this feature?

The knowledge base alludes to MegaPOV having some blurred reflection 
capability, though I cannot find it in the MegaPOV documentation.  But 
MegaPOV development terminated long before UberPOV was released.

Since development of UberPOV has wound down, I've found myself reverting 
to RC3Metal from the Object Collection, which works with standard 
POV-Ray.  What seems to work best for me with RC3Metal is to do a bunch 
of EXR renders with different seeds in an animation loop, then read them 
back as image maps and average them in a pigment_map.  To save time, I 
save the photons for the first 3 to 5 frames, then reuse them round 
robin for the remaining frames.  If there are no mutually reflecting 
surfaces, I just use a single render with a high sample count.

Overall, UberPOV does a better job than RC3Metal, though, especially 
with specular highlights.

[Mr] Re: Hgpovray38, current state [2164 days 5 hours and 58 minutes ago]

Sun, 10 May 2020 10:10:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 09/05/2020 Ã  14:49, Mr a Ã©critÂ :
> > Le_Forgeron <jgr### [at] freefr> wrote:
> >> Le 18/08/2018 ÃƒÂ  13:58, Le_Forgeron a
ÃƒÂ©critÃ‚Â :
> >>> For the people who do not want to bother with git, Hgpovray is now
> >>> available as sources
> >>>
> >>>
> >> Latest version so far:
> >>
> >> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
> >>
> >>> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
> >>
> >>
> >>> More works on the agenda :
> >>>
> >>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> >>>
> >
> > Bonjour !
> >
> > I just tried to build the latest HG-Pov I could find which seems to be that
> > Bigarade, right? Using MS VS2015,
> > Here is VS2015 build output:
> >
> > 1>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : vfewin, ConfigurationÂ : Debug x64
> > ------
> > 2>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : rtrsupport, ConfigurationÂ : Debug x64
> > ------
> > 3>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povbackend, ConfigurationÂ : Debug x64
> > ------
> > 4>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povbase, ConfigurationÂ : Debug x64
> > ------
> > 5>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povfrontend, ConfigurationÂ : Debug
> > x64 ------
> > 6>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : boost_date_time, ConfigurationÂ : Debug
> > x64 ------
> > 6>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette configuration
> > de solution
> > 7>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povcore, ConfigurationÂ : Debug x64
> > ------
> > 8>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povparser, ConfigurationÂ : Debug x64
> > ------
> > 1>  vfesession.cpp
> > 2>  vidcapimpl.cpp
> > 3>  boundingtask.cpp
> > 5>  povmain.cpp
> > 4>  colour.cpp
> > 7>  bounding.cpp
> > 8>  parser.cpp
> > 7>  texture.cpp
> > 4>  metadata.cpp
> > 3>..\..\source\backend\bounding\boundingtask.cpp(91): warning C4267:
'return'Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(162): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(163): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(178): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>..\..\source\backend\bounding\boundingtask.cpp(179): warning C4267:
'='Â :
> > conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 3>  povray.cpp
> > 7>  scenedata.cpp
> > 5>povmain.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 5>  povfrontend.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povfrontend64d.lib
> > 3>..\..\source\backend\povray.cpp(515): warning C4267: 'argument'Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 3>  benchmark.cpp
> > 3>  renderbackend.cpp
> > 7>  tracethreaddata.cpp
> > 8>..\..\source\parser\parser.cpp(9673): warning C4267: 'argument'Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12022): error C2146: erreur de
syntaxeÂ :
> > absence de ';' avant l'identificateur 'idx1'
> > 4>  mathutil.cpp
> > 8>..\..\source\parser\parser.cpp(12022): error C2065: 'idx1'Â :
identificateur
> > non dÃ©clarÃ©
> > 4>  GÃ©nÃ©ration de code en cours...
> > 8>..\..\source\parser\parser.cpp(12023): error C2065: 'ssize_t'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12023): error C2146: erreur de
syntaxeÂ :
> > absence de ';' avant l'identificateur 'idx2'
> > 8>..\..\source\parser\parser.cpp(12023): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx1'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12026): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12028): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx1'Â :
identificateur
> > non dÃ©clarÃ©
> > 8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx2'Â :
identificateur
> > non dÃ©clarÃ©
> > 4>  jpeg.cpp
> > 8>  parser_strings.cpp
> > 7>  box.cpp
> > 3>  scene.cpp
> > 7>  GÃ©nÃ©ration de code en cours...
> > 4>..\..\source\base\image\jpeg.cpp(502): warning C4267: 'argument'Â :
conversion
> > de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> > 8>..\..\source\parser\parser_strings.cpp(479): error C2131: l'expression n'a pas
> > Ã©tÃ© Ã©valuÃ©e en constante
> > 8>  ..\..\source\parser\parser_strings.cpp(479): note: Ã©chec en raison
> > d'arguments non constants ou d'une rÃ©fÃ©rence Ã  un
symbole non constant
> > 8>  ..\..\source\parser\parser_strings.cpp(479): note: voir l'utilisation de
> > 'this'
> > 8>..\..\source\parser\parser_strings.cpp(708): warning C4267: '='Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>..\..\source\parser\parser_strings.cpp(1176): warning C4267: '='Â :
conversion
> > de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>  parser_tokenizer.cpp
> > 3>  GÃ©nÃ©ration de code en cours...
> > 8>..\..\source\parser\parser_tokenizer.cpp(1514): warning C4267: '='Â :
> > conversion de 'size_t' en 'int', perte possible de donnÃ©es
> > 7>bounding.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 4>  png.cpp
> > 8>..\..\source\parser\parser_tokenizer.cpp(3915): warning C4267: '='Â :
> > conversion de 'size_t' en 'int', perte possible de donnÃ©es
> > 2>  vidcap.cpp
> > 8>..\..\source\parser\parser_tokenizer.cpp(3935): warning C4267: '='Â :
> > conversion de 'size_t' en 'int', perte possible de donnÃ©es
> > 8>  GÃ©nÃ©ration de code en cours...
> > 3>  povbackend.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbackend64d.lib
> > 7>  povcore.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povcore64d.lib
> > 4>  GÃ©nÃ©ration de code en cours...
> > 4>timer.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 4>mathutil.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 4>  povbase.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbase64d.lib
> > 2>  rtrsupport.cpp
> > 1>  vfewin.vcxproj ->
> > C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\vfe64d.lib
> > 2>  GÃ©nÃ©ration de code en cours...
> > 2>vidcap.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> > publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> > opÃšration de lien utilisant cette bibliothÃžque
> > 2>  rtrsupport.vcxproj ->
> >
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\rtrsupport64d.lib
> > 9>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : tests, ConfigurationÂ : Debug x64 ------
> > 9>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette configuration
> > de solution
> > 10>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : GUI, ConfigurationÂ : Debug x64
> > ------
> > 11>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : console, ConfigurationÂ : Debug x64
> > ------
> > 11>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette
> > configuration de solution
> > 10>  pvbitmap.cpp
> > 10>  pvdialog.cpp
> > 10>  pvdisplay.cpp
> > 10>  pvedit.cpp
> > 10>..\pvedit.cpp(301): warning C4267: '+='Â : conversion de 'size_t' en
'int',
> > perte possible de donnÃ©es
> > 10>  pvengine.cpp
> > 10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(1544): warning
> > C4091: 'typedef 'Â : ignorÃ© Ã  gauche de '' quand
aucune variable n'est dÃ©clarÃ©e
> > 10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(3190): warning
> > C4091: 'typedef 'Â : ignorÃ© Ã  gauche de '' quand
aucune variable n'est dÃ©clarÃ©e
> > 10>..\pvengine.cpp(498): warning C4838: la conversion de 'int' en 'WORD'
> > requiert une conversion restrictive
> > 10>..\pvengine.cpp(1721): warning C4477: 'sprintf'Â : la
chaÃ®ne de format '%p'
> > nÃ©cessite un argument de type 'void *', mais l'argument variadique 2
est de type
> > 'DWORD64'
> > 10>..\pvengine.cpp(5152): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> > dÃ©conseillÃ©
> > 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> > voir la dÃ©claration de 'GetVersionExA'
> > 10>..\pvengine.cpp(5608): warning C4267: '='Â : conversion de 'size_t'
en
> > 'unsigned int', perte possible de donnÃ©es
> > 10>..\pvengine.cpp(5787): warning C4267: '='Â : conversion de 'size_t'
en
> > 'unsigned int', perte possible de donnÃ©es
> > 10>..\pvengine.cpp(5719): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> > dÃ©conseillÃ©
> > 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> > voir la dÃ©claration de 'GetVersionExA'
> > 10>  pvfiles.cpp
> > 10>  pvfrontend.cpp
> > 10>  pvguiext.cpp
> > 10>  pvmem.cpp
> > 10>  pvmenu.cpp
> > 10>  pvmisc.cpp
> > 10>..\pvmisc.cpp(223): warning C4838: la conversion de 'int' en 'unsigned int'
> > requiert une conversion restrictive
> > 10>  pvtext.cpp
> > 10>  pvupdate.cpp
> > 10>..\pvupdate.cpp(166): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> > dÃ©conseillÃ©
> > 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> > voir la dÃ©claration de 'GetVersionExA'
> > 10>  GÃ©nÃ©ration de code en cours...
> > 10>LINK : fatal error LNK1104: impossible d'ouvrir le fichier
> >
'C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povparser64d.lib'
> > ========== GÃ©nÃ©rationÂ : 6 a rÃ©ussi, 2
a Ã©chouÃ©, 15 mis Ã  jour, 3 a
Ã©tÃ© ignorÃ©
> > ==========
> >
> >
> >
> >
>
> you can fix the ssize_t error by defining it as a signed integer such as
> int_least32_t

Does that mean I need to learn C to test the branch? :-)

[Le Forgeron] Re: Hgpovray38, current state [2164 days 6 hours and 53 minutes ago]

Sun, 10 May 2020 09:15:02 GMT

Le 09/05/2020 Ã  14:49, Mr a Ã©critÂ :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 18/08/2018 ÃƒÂ  13:58, Le_Forgeron a
ÃƒÂ©critÃ‚Â :
>>> For the people who do not want to bother with git, Hgpovray is now
>>> available as sources
>>>
>>>
>> Latest version so far:
>>
>> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
>>
>>> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
>>
>>
>>> More works on the agenda :
>>>
>>> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>>>
> 
> Bonjour !
> 
> I just tried to build the latest HG-Pov I could find which seems to be that
> Bigarade, right? Using MS VS2015,
> Here is VS2015 build output:
> 
> 1>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : vfewin, ConfigurationÂ : Debug x64
> ------
> 2>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : rtrsupport, ConfigurationÂ : Debug x64
> ------
> 3>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povbackend, ConfigurationÂ : Debug x64
> ------
> 4>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povbase, ConfigurationÂ : Debug x64
> ------
> 5>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povfrontend, ConfigurationÂ : Debug
> x64 ------
> 6>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : boost_date_time, ConfigurationÂ : Debug
> x64 ------
> 6>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette configuration
> de solution
> 7>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povcore, ConfigurationÂ : Debug x64
> ------
> 8>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : povparser, ConfigurationÂ : Debug x64
> ------
> 1>  vfesession.cpp
> 2>  vidcapimpl.cpp
> 3>  boundingtask.cpp
> 5>  povmain.cpp
> 4>  colour.cpp
> 7>  bounding.cpp
> 8>  parser.cpp
> 7>  texture.cpp
> 4>  metadata.cpp
> 3>..\..\source\backend\bounding\boundingtask.cpp(91): warning C4267:
'return'Â :
> conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> 3>..\..\source\backend\bounding\boundingtask.cpp(162): warning C4267:
'='Â :
> conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> 3>..\..\source\backend\bounding\boundingtask.cpp(163): warning C4267:
'='Â :
> conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> 3>..\..\source\backend\bounding\boundingtask.cpp(178): warning C4267:
'='Â :
> conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> 3>..\..\source\backend\bounding\boundingtask.cpp(179): warning C4267:
'='Â :
> conversion de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> 3>  povray.cpp
> 7>  scenedata.cpp
> 5>povmain.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> opÃšration de lien utilisant cette bibliothÃžque
> 5>  povfrontend.vcxproj ->
>
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povfrontend64d.lib
> 3>..\..\source\backend\povray.cpp(515): warning C4267: 'argument'Â :
conversion
> de 'size_t' en 'int', perte possible de donnÃ©es
> 3>  benchmark.cpp
> 3>  renderbackend.cpp
> 7>  tracethreaddata.cpp
> 8>..\..\source\parser\parser.cpp(9673): warning C4267: 'argument'Â :
conversion
> de 'size_t' en 'int', perte possible de donnÃ©es
> 8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12022): error C2146: erreur de syntaxeÂ :
> absence de ';' avant l'identificateur 'idx1'
> 4>  mathutil.cpp
> 8>..\..\source\parser\parser.cpp(12022): error C2065: 'idx1'Â :
identificateur
> non dÃ©clarÃ©
> 4>  GÃ©nÃ©ration de code en cours...
> 8>..\..\source\parser\parser.cpp(12023): error C2065: 'ssize_t'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12023): error C2146: erreur de syntaxeÂ :
> absence de ';' avant l'identificateur 'idx2'
> 8>..\..\source\parser\parser.cpp(12023): error C2065: 'idx2'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx1'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx2'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12026): error C2065: 'idx2'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12028): error C2065: 'idx2'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx1'Â :
identificateur
> non dÃ©clarÃ©
> 8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx2'Â :
identificateur
> non dÃ©clarÃ©
> 4>  jpeg.cpp
> 8>  parser_strings.cpp
> 7>  box.cpp
> 3>  scene.cpp
> 7>  GÃ©nÃ©ration de code en cours...
> 4>..\..\source\base\image\jpeg.cpp(502): warning C4267: 'argument'Â :
conversion
> de 'size_t' en 'unsigned int', perte possible de donnÃ©es
> 8>..\..\source\parser\parser_strings.cpp(479): error C2131: l'expression n'a pas
> Ã©tÃ© Ã©valuÃ©e en constante
> 8>  ..\..\source\parser\parser_strings.cpp(479): note: Ã©chec en raison
> d'arguments non constants ou d'une rÃ©fÃ©rence Ã  un
symbole non constant
> 8>  ..\..\source\parser\parser_strings.cpp(479): note: voir l'utilisation de
> 'this'
> 8>..\..\source\parser\parser_strings.cpp(708): warning C4267: '='Â :
conversion
> de 'size_t' en 'int', perte possible de donnÃ©es
> 8>..\..\source\parser\parser_strings.cpp(1176): warning C4267: '='Â :
conversion
> de 'size_t' en 'int', perte possible de donnÃ©es
> 8>  parser_tokenizer.cpp
> 3>  GÃ©nÃ©ration de code en cours...
> 8>..\..\source\parser\parser_tokenizer.cpp(1514): warning C4267: '='Â :
> conversion de 'size_t' en 'int', perte possible de donnÃ©es
> 7>bounding.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> opÃšration de lien utilisant cette bibliothÃžque
> 4>  png.cpp
> 8>..\..\source\parser\parser_tokenizer.cpp(3915): warning C4267: '='Â :
> conversion de 'size_t' en 'int', perte possible de donnÃ©es
> 2>  vidcap.cpp
> 8>..\..\source\parser\parser_tokenizer.cpp(3935): warning C4267: '='Â :
> conversion de 'size_t' en 'int', perte possible de donnÃ©es
> 8>  GÃ©nÃ©ration de code en cours...
> 3>  povbackend.vcxproj ->
>
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbackend64d.lib
> 7>  povcore.vcxproj ->
> C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povcore64d.lib
> 4>  GÃ©nÃ©ration de code en cours...
> 4>timer.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> opÃšration de lien utilisant cette bibliothÃžque
> 4>mathutil.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> opÃšration de lien utilisant cette bibliothÃžque
> 4>  povbase.vcxproj ->
> C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbase64d.lib
> 2>  rtrsupport.cpp
> 1>  vfewin.vcxproj ->
> C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\vfe64d.lib
> 2>  GÃ©nÃ©ration de code en cours...
> 2>vidcap.obj : warning LNK4221: Ce fichier objet ne dÃšfinit pas de
symboles
> publics jusqu'ici non dÃšfinis. Par consÃšquent, il ne sera
utilisÃš par aucune
> opÃšration de lien utilisant cette bibliothÃžque
> 2>  rtrsupport.vcxproj ->
>
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\rtrsupport64d.lib
> 9>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : tests, ConfigurationÂ : Debug x64 ------
> 9>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette configuration
> de solution
> 10>------ DÃ©but de la gÃ©nÃ©rationÂ :
ProjetÂ : GUI, ConfigurationÂ : Debug x64
> ------
> 11>------ GÃ©nÃ©ration ignorÃ©eÂ :
ProjetÂ : console, ConfigurationÂ : Debug x64
> ------
> 11>Projet non sÃ©lectionnÃ© dans le cadre d'une
gÃ©nÃ©ration pour cette
> configuration de solution
> 10>  pvbitmap.cpp
> 10>  pvdialog.cpp
> 10>  pvdisplay.cpp
> 10>  pvedit.cpp
> 10>..\pvedit.cpp(301): warning C4267: '+='Â : conversion de 'size_t' en
'int',
> perte possible de donnÃ©es
> 10>  pvengine.cpp
> 10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(1544): warning
> C4091: 'typedef 'Â : ignorÃ© Ã  gauche de '' quand
aucune variable n'est dÃ©clarÃ©e
> 10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(3190): warning
> C4091: 'typedef 'Â : ignorÃ© Ã  gauche de '' quand
aucune variable n'est dÃ©clarÃ©e
> 10>..\pvengine.cpp(498): warning C4838: la conversion de 'int' en 'WORD'
> requiert une conversion restrictive
> 10>..\pvengine.cpp(1721): warning C4477: 'sprintf'Â : la chaÃ®ne
de format '%p'
> nÃ©cessite un argument de type 'void *', mais l'argument variadique 2 est
de type
> 'DWORD64'
> 10>..\pvengine.cpp(5152): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> dÃ©conseillÃ©
> 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> voir la dÃ©claration de 'GetVersionExA'
> 10>..\pvengine.cpp(5608): warning C4267: '='Â : conversion de 'size_t' en
> 'unsigned int', perte possible de donnÃ©es
> 10>..\pvengine.cpp(5787): warning C4267: '='Â : conversion de 'size_t' en
> 'unsigned int', perte possible de donnÃ©es
> 10>..\pvengine.cpp(5719): warning C4996: 'GetVersionExA': a
Ã©tÃ© dÃ©clarÃ©
> dÃ©conseillÃ©
> 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> voir la dÃ©claration de 'GetVersionExA'
> 10>  pvfiles.cpp
> 10>  pvfrontend.cpp
> 10>  pvguiext.cpp
> 10>  pvmem.cpp
> 10>  pvmenu.cpp
> 10>  pvmisc.cpp
> 10>..\pvmisc.cpp(223): warning C4838: la conversion de 'int' en 'unsigned int'
> requiert une conversion restrictive
> 10>  pvtext.cpp
> 10>  pvupdate.cpp
> 10>..\pvupdate.cpp(166): warning C4996: 'GetVersionExA': a Ã©tÃ©
dÃ©clarÃ©
> dÃ©conseillÃ©
> 10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
> voir la dÃ©claration de 'GetVersionExA'
> 10>  GÃ©nÃ©ration de code en cours...
> 10>LINK : fatal error LNK1104: impossible d'ouvrir le fichier
>
'C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povparser64d.lib'
> ========== GÃ©nÃ©rationÂ : 6 a rÃ©ussi, 2 a
Ã©chouÃ©, 15 mis Ã  jour, 3 a Ã©tÃ©
ignorÃ©
> ==========
> 
> 
> 
> 

you can fix the ssize_t error by defining it as a signed integer such as
int_least32_t

[William F Pokorny] Re: Blurred reflections [2164 days 14 hours and 23 minutes ago]

Sun, 10 May 2020 01:44:48 GMT

On 5/9/20 4:29 PM, Mr wrote:
> "And" <49341109@ntnu.edu.tw> wrote:
>> Will blurred reflection integrate into official version one day? (this function
>> is too important)
> Things did evolve in the last two years. Now that Anti Aliasing method 3 is in
> the main POV-Ray trunk, the said "framework" is there. The syntax... almost as
> well, with things like the finish level fresnel paving the way to a similar
> approach for roughness maybe. My question is, since then, did any other branch
> than Uberpov also try to add this feature?
> 
> 
I'm not aware of any.

Bill P.

[Mr] Re: Blurred reflections [2164 days 19 hours and 38 minutes ago]

Sat, 9 May 2020 20:30:06 GMT

"And" <49341109@ntnu.edu.tw> wrote:
> Will blurred reflection integrate into official version one day? (this function
> is too important)
Things did evolve in the last two years. Now that Anti Aliasing method 3 is in
the main POV-Ray trunk, the said "framework" is there. The syntax... almost as
well, with things like the finish level fresnel paving the way to a similar
approach for roughness maybe. My question is, since then, did any other branch
than Uberpov also try to add this feature?

[Mr] Re: Hgpovray38, current state [2165 days 3 hours and 18 minutes ago]

Sat, 9 May 2020 12:50:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 18/08/2018 Ã  13:58, Le_Forgeron a Ã©critÂ :
> > For the people who do not want to bother with git, Hgpovray is now
> > available as sources
> >
> >
> Latest version so far:
>
> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
>
> > https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
>
>
> > More works on the agenda :
> >
> > http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
> >

Bonjour !

I just tried to build the latest HG-Pov I could find which seems to be that
Bigarade, right? Using MS VS2015,
Here is VS2015 build output:

1>------ Début de la génération : Projet : vfewin,
Configuration : Debug x64
------
2>------ Début de la génération : Projet : rtrsupport,
Configuration : Debug x64
------
3>------ Début de la génération : Projet : povbackend,
Configuration : Debug x64
------
4>------ Début de la génération : Projet : povbase,
Configuration : Debug x64
------
5>------ Début de la génération : Projet : povfrontend,
Configuration : Debug
x64 ------
6>------ Génération ignorée : Projet : boost_date_time,
Configuration : Debug
x64 ------
6>Projet non sélectionné dans le cadre d'une génération pour cette
configuration
de solution
7>------ Début de la génération : Projet : povcore,
Configuration : Debug x64
------
8>------ Début de la génération : Projet : povparser,
Configuration : Debug x64
------
1>  vfesession.cpp
2>  vidcapimpl.cpp
3>  boundingtask.cpp
5>  povmain.cpp
4>  colour.cpp
7>  bounding.cpp
8>  parser.cpp
7>  texture.cpp
4>  metadata.cpp
3>..\..\source\backend\bounding\boundingtask.cpp(91): warning C4267: 'return' :
conversion de 'size_t' en 'unsigned int', perte possible de données
3>..\..\source\backend\bounding\boundingtask.cpp(162): warning C4267: '=' :
conversion de 'size_t' en 'unsigned int', perte possible de données
3>..\..\source\backend\bounding\boundingtask.cpp(163): warning C4267: '=' :
conversion de 'size_t' en 'unsigned int', perte possible de données
3>..\..\source\backend\bounding\boundingtask.cpp(178): warning C4267: '=' :
conversion de 'size_t' en 'unsigned int', perte possible de données
3>..\..\source\backend\bounding\boundingtask.cpp(179): warning C4267: '=' :
conversion de 'size_t' en 'unsigned int', perte possible de données
3>  povray.cpp
7>  scenedata.cpp
5>povmain.obj : warning LNK4221: Ce fichier objet ne dÚfinit pas de symboles
publics jusqu'ici non dÚfinis. Par consÚquent, il ne sera utilisÚ par
aucune
opÚration de lien utilisant cette bibliothÞque
5>  povfrontend.vcxproj ->
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povfrontend64d.lib
3>..\..\source\backend\povray.cpp(515): warning C4267: 'argument' : conversion
de 'size_t' en 'int', perte possible de données
3>  benchmark.cpp
3>  renderbackend.cpp
7>  tracethreaddata.cpp
8>..\..\source\parser\parser.cpp(9673): warning C4267: 'argument' : conversion
de 'size_t' en 'int', perte possible de données
8>..\..\source\parser\parser.cpp(12022): error C2065: 'ssize_t' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12022): error C2146: erreur de syntaxe :
absence de ';' avant l'identificateur 'idx1'
4>  mathutil.cpp
8>..\..\source\parser\parser.cpp(12022): error C2065: 'idx1' : identificateur
non déclaré
4>  Génération de code en cours...
8>..\..\source\parser\parser.cpp(12023): error C2065: 'ssize_t' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12023): error C2146: erreur de syntaxe :
absence de ';' avant l'identificateur 'idx2'
8>..\..\source\parser\parser.cpp(12023): error C2065: 'idx2' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx1' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12024): error C2065: 'idx2' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12026): error C2065: 'idx2' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12028): error C2065: 'idx2' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx1' : identificateur
non déclaré
8>..\..\source\parser\parser.cpp(12031): error C2065: 'idx2' : identificateur
non déclaré
4>  jpeg.cpp
8>  parser_strings.cpp
7>  box.cpp
3>  scene.cpp
7>  Génération de code en cours...
4>..\..\source\base\image\jpeg.cpp(502): warning C4267: 'argument' : conversion
de 'size_t' en 'unsigned int', perte possible de données
8>..\..\source\parser\parser_strings.cpp(479): error C2131: l'expression n'a pas
été évaluée en constante
8>  ..\..\source\parser\parser_strings.cpp(479): note: échec en raison
d'arguments non constants ou d'une référence à un symbole non constant
8>  ..\..\source\parser\parser_strings.cpp(479): note: voir l'utilisation de
'this'
8>..\..\source\parser\parser_strings.cpp(708): warning C4267: '=' : conversion
de 'size_t' en 'int', perte possible de données
8>..\..\source\parser\parser_strings.cpp(1176): warning C4267: '=' : conversion
de 'size_t' en 'int', perte possible de données
8>  parser_tokenizer.cpp
3>  Génération de code en cours...
8>..\..\source\parser\parser_tokenizer.cpp(1514): warning C4267: '=' :
conversion de 'size_t' en 'int', perte possible de données
7>bounding.obj : warning LNK4221: Ce fichier objet ne dÚfinit pas de symboles
publics jusqu'ici non dÚfinis. Par consÚquent, il ne sera utilisÚ par
aucune
opÚration de lien utilisant cette bibliothÞque
4>  png.cpp
8>..\..\source\parser\parser_tokenizer.cpp(3915): warning C4267: '=' :
conversion de 'size_t' en 'int', perte possible de données
2>  vidcap.cpp
8>..\..\source\parser\parser_tokenizer.cpp(3935): warning C4267: '=' :
conversion de 'size_t' en 'int', perte possible de données
8>  Génération de code en cours...
3>  povbackend.vcxproj ->
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbackend64d.lib
7>  povcore.vcxproj ->
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povcore64d.lib
4>  Génération de code en cours...
4>timer.obj : warning LNK4221: Ce fichier objet ne dÚfinit pas de symboles
publics jusqu'ici non dÚfinis. Par consÚquent, il ne sera utilisÚ par
aucune
opÚration de lien utilisant cette bibliothÞque
4>mathutil.obj : warning LNK4221: Ce fichier objet ne dÚfinit pas de symboles
publics jusqu'ici non dÚfinis. Par consÚquent, il ne sera utilisÚ par
aucune
opÚration de lien utilisant cette bibliothÞque
4>  povbase.vcxproj ->
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povbase64d.lib
2>  rtrsupport.cpp
1>  vfewin.vcxproj ->
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\vfe64d.lib
2>  Génération de code en cours...
2>vidcap.obj : warning LNK4221: Ce fichier objet ne dÚfinit pas de symboles
publics jusqu'ici non dÚfinis. Par consÚquent, il ne sera utilisÚ par
aucune
opÚration de lien utilisant cette bibliothÞque
2>  rtrsupport.vcxproj ->
C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\rtrsupport64d.lib
9>------ Génération ignorée : Projet : tests,
Configuration : Debug x64 ------
9>Projet non sélectionné dans le cadre d'une génération pour cette
configuration
de solution
10>------ Début de la génération : Projet : GUI,
Configuration : Debug x64
------
11>------ Génération ignorée : Projet : console,
Configuration : Debug x64
------
11>Projet non sélectionné dans le cadre d'une génération pour
cette
configuration de solution
10>  pvbitmap.cpp
10>  pvdialog.cpp
10>  pvdisplay.cpp
10>  pvedit.cpp
10>..\pvedit.cpp(301): warning C4267: '+=' : conversion de 'size_t' en 'int',
perte possible de données
10>  pvengine.cpp
10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(1544): warning
C4091: 'typedef ' : ignoré à gauche de '' quand aucune variable n'est
déclarée
10>C:\Program Files (x86)\Windows Kits\8.1\Include\um\dbghelp.h(3190): warning
C4091: 'typedef ' : ignoré à gauche de '' quand aucune variable n'est
déclarée
10>..\pvengine.cpp(498): warning C4838: la conversion de 'int' en 'WORD'
requiert une conversion restrictive
10>..\pvengine.cpp(1721): warning C4477: 'sprintf' : la chaîne de format
'%p'
nécessite un argument de type 'void *', mais l'argument variadique 2 est de type
'DWORD64'
10>..\pvengine.cpp(5152): warning C4996: 'GetVersionExA': a été
déclaré
déconseillé
10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
voir la déclaration de 'GetVersionExA'
10>..\pvengine.cpp(5608): warning C4267: '=' : conversion de 'size_t' en
'unsigned int', perte possible de données
10>..\pvengine.cpp(5787): warning C4267: '=' : conversion de 'size_t' en
'unsigned int', perte possible de données
10>..\pvengine.cpp(5719): warning C4996: 'GetVersionExA': a été
déclaré
déconseillé
10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
voir la déclaration de 'GetVersionExA'
10>  pvfiles.cpp
10>  pvfrontend.cpp
10>  pvguiext.cpp
10>  pvmem.cpp
10>  pvmenu.cpp
10>  pvmisc.cpp
10>..\pvmisc.cpp(223): warning C4838: la conversion de 'int' en 'unsigned int'
requiert une conversion restrictive
10>  pvtext.cpp
10>  pvupdate.cpp
10>..\pvupdate.cpp(166): warning C4996: 'GetVersionExA': a été
déclaré
déconseillé
10>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h(433): note:
voir la déclaration de 'GetVersionExA'
10>  Génération de code en cours...
10>LINK : fatal error LNK1104: impossible d'ouvrir le fichier
'C:\HG-POV\povray-3.8.0.alpha-Hg.226.Bigarade\windows\vs2015\bin64\lib\povparser64d.lib'
========== Génération : 6 a réussi, 2 a échoué, 15 mis
à jour, 3 a été ignoré
==========

[Dick Balaska] Re: qtpovray 3.80.14 [2195 days and 31 minutes ago]

Thu, 9 Apr 2020 15:36:36 GMT

Am 4/9/20 10:50 AM, also sprach B. Gimeno:
> Dick Balaska <dic### [at] buckosoftcom> wrote:
>> https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.14
>> https://launchpad.net/~qtpovray/+archive/ubuntu/qtpovray
>>
>> Bug 26 - Add an SDL debugger to qtpovray
>>            http://www.buckosoft.com/qtpovray/debugger.html
>> --
>> dik
>> Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)
> 
> While I'm trying to compile this source after succefully installed the official
> 3.8 release on a standard Ubuntu Lts system. I stumble upon this message.
> 
> //-------------------------------------------------------
> In file included from ./parser/debugger.h:27:0,
>                   from ./parser/parser.h:84,
>                   from backend/control/parsertask.cpp:52:
> ../parser/povdbgobject.h:24:10: QJsonObject: no such file or directory
>   #include <QJsonObject>
>            ^~~~~~~~~~~~~
> //-------------------------------------------------------
> 
>   What am I needing here?
> 
> Thanks, bgimeno
> 
> 

What version of Ubuntu? What version of Qt?

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[B Gimeno] Re: qtpovray 3.80.14 [2195 days 1 hour and 13 minutes ago]

Thu, 9 Apr 2020 14:55:00 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:
> https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.14
> https://launchpad.net/~qtpovray/+archive/ubuntu/qtpovray
>
> Bug 26 - Add an SDL debugger to qtpovray
>           http://www.buckosoft.com/qtpovray/debugger.html
> --
> dik
> Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

While I'm trying to compile this source after succefully installed the official
3.8 release on a standard Ubuntu Lts system. I stumble upon this message.

//-------------------------------------------------------
In file included from ./parser/debugger.h:27:0,
                 from ./parser/parser.h:84,
                 from backend/control/parsertask.cpp:52:
../parser/povdbgobject.h:24:10: QJsonObject: no such file or directory
 #include <QJsonObject>
          ^~~~~~~~~~~~~
//-------------------------------------------------------

 What am I needing here?

Thanks, bgimeno

[Dick Balaska] qtpovray 3.80.14 [2195 days 10 hours and 19 minutes ago]

Thu, 9 Apr 2020 05:49:10 GMT

https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.14
https://launchpad.net/~qtpovray/+archive/ubuntu/qtpovray

Bug 26 - Add an SDL debugger to qtpovray
          http://www.buckosoft.com/qtpovray/debugger.html
-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Dick Balaska] Re: SDL debugging [2239 days 11 hours and 14 minutes ago]

Tue, 25 Feb 2020 04:53:57 GMT

Am 2/11/20 2:48 PM, also sprach Bald Eagle:

> 
> 1. I would LOVE to have a basic sanity check.  Is there a light source?  Is
> there even a camera?

I can do those, but it seems they should be POV-Ray warnings.

>   Are there any objects in the camera view?  Are there any
> outside the camera view?

That's raytracing. :)  I'm just doing the SDL parser.
You currently get the
"Ray->Shape Intersection          Tests       Succeeded  Percentage"
table.

> 2. globally declared constants, variables, etc.
Yes, it does that.

> 3. Let's suppose you write a bunch of code, or include some files --- do they
> get used?  Is there any way to check for superfluousness?

A list of files that were included is interesting.
They "get used" by virtue of being included.
"superfluousness"? Dude...

> Are there objects that get declared and then not instantiated?

I maybe could do this.  A couple of things.
0) I would have to track the objects, modify the POV-Ray code.
    I am loathe to do that.  Currently I have a one line change
    to all of POV-Ray parser proper: the parser calls
    checkForBreakpoint() after each token. [*1]
1) This would be super messy.  It would require a beefy filter system.
    You really don't want a report that you didn't use DimGrey
    or DimGray or 400 other colors, and woods, etc.
2) What about objects in a macro that gets used multiple times?  Messy.
3) My user base is like 5.  This is a ton of work with not much payback.

*1 And a path through the message system, which was several changes...

> 4. are you using the best/latest version? 

version of what?

> Are you using something that is slow
> or inaccurate when you could be using something that works better/faster?

"something"?

> 5. check for coincident or nearly coincident surfaces.

That's raytracing.

> 6. some sort of "nesting" indicator for showing "where" in the code things went
> haywire.  Are we in a loop, include file, something else?

Define haywire.

> 7. Maybe some kind of magic talisman to ward off infinite loops...  :O

Currently, you can break inside an infinite loop and with the power of 
stepping to the next executed line and watching variables, see what's 
wrong with your loop.

> 
> I'd say that if you're writing a "debugger" - then #1 on my list would be - what
> do people waste hundreds of threads rehashing, and what are the top 20 things
> that people mess up.   The error messages are garbage for the most part.
> "cannot pass uninitialized Lvalue to..."   OK, so WHICH "Lvalue" is
> uninitialized?

I don't get why name, file, line, col isn't part of a lot of error
messages.  Same thing with
'Parse Warning: Should have at least 2 objects in csg.'
Clearly, you have some idea of where you're looking, Mr. Computer.

On the flip side of that, there is now a lot of garbage error messages 
that are not errors.  I get ~50 'Possible Parse Error: Text may not be 
displayed as expected'.  It's so bad I had to turn off errors in 
qtpovray. This messes up my work flow now because "nothing happened. Did 
I press render?  Yes.  [ pause a beat ] Oh, I turned off errors. Turn 
them back on..."

I am very tempted to fix these in POV-Ray.  But then I deviate from 
POV-Ray proper and the odds of getting these fixes into the main tree is 
pretty much 0.

> 
> You get the idea...
> 
> 



-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[jr] Re: SDL debugging [2252 days 1 hour and 53 minutes ago]

Wed, 12 Feb 2020 14:15:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 1/16/20 12:58 AM, also sprach Dick Balaska:
> > I have written an SDL debugger for qtpovray.
>
> Phase 2, in which Doris gets her oats.  ...
>
> All that wasted space in the lower left. I don't know what to do with
> that.  ...

a view of the bounding boxes of the scene?  rotatable.  :-)

+1 for BE's point re basic sanity checking.


regards, jr.

[Bald Eagle] Re: SDL debugging [2252 days 20 hours and 18 minutes ago]

Tue, 11 Feb 2020 19:50:06 GMT

Dick Balaska <dic### [at] buckosoftcom> wrote:
> Am 1/16/20 12:58 AM, also sprach Dick Balaska:
> > I have written an SDL debugger for qtpovray.

At some point, I'm going to model and render a shrine to you.   :)

> I had fun recursively evaluating arrays of arrays. It was a nice
> challenge.  :)

Have you tried skipping elements and leaving some undefined?

> I can evaluate a camera, but man, evaluating a CSG object is not going
> well. :(

I can see CSG getting very complicated, very quickly.

> All that wasted space in the lower left. I don't know what to do with
> that.

1. I would LOVE to have a basic sanity check.  Is there a light source?  Is
there even a camera?   Are there any objects in the camera view?  Are there any
outside the camera view?
2. globally declared constants, variables, etc.
3. Let's suppose you write a bunch of code, or include some files --- do they
get used?  Is there any way to check for superfluousness?
Are there objects that get declared and then not instantiated?
4. are you using the best/latest version? Are you using something that is slow
or inaccurate when you could be using something that works better/faster?
5. check for coincident or nearly coincident surfaces.
6. some sort of "nesting" indicator for showing "where" in the code things went
haywire.  Are we in a loop, include file, something else?
7. Maybe some kind of magic talisman to ward off infinite loops...  :O

I'd say that if you're writing a "debugger" - then #1 on my list would be - what
do people waste hundreds of threads rehashing, and what are the top 20 things
that people mess up.   The error messages are garbage for the most part.
"cannot pass uninitialized Lvalue to..."   OK, so WHICH "Lvalue" is
uninitialized?

You get the idea...

[Dick Balaska] Re: SDL debugging [2252 days 22 hours and 57 minutes ago]

Tue, 11 Feb 2020 17:10:41 GMT

Am 1/16/20 12:58 AM, also sprach Dick Balaska:
> I have written an SDL debugger for qtpovray.
> 

Phase 2, in which Doris gets her oats.

I had fun recursively evaluating arrays of arrays. It was a nice 
challenge.  :)

I can evaluate a camera, but man, evaluating a CSG object is not going 
well. :(

All that wasted space in the lower left. I don't know what to do with 
that.  Originally I had thought a debugger console (a la gdb) but I 
don't need that.

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Dick Balaska] Re: SDL debugging [2278 days 15 hours and 49 minutes ago]

Fri, 17 Jan 2020 00:19:06 GMT

Am 1/16/20 3:53 AM, also sprach jr:

> 
> what plans do you have for dealing with objects and/or object identifiers?

All identifiers are easy.  After I posted, I wished I'd added "White" to 
my Symbol list, which shows its Type as "colour" and Value as 
"<unhandled type>".  POV-Ray has text-name mappings for all types for 
error handling. ("Expected float identifier, found colour indentifier")

For objects,
the QTableWidget I used is the simplest way to display tabular data and 
is just a PoC here.  During my Minecraft wanderings, I wrote Yet Another 
Minecraft Editor.  Minecraft data is not unlike POV-Ray data, a tree of 
random binary types.
http://www.buckosoft.com/yamce/g/resourceTop.png
The point there being, I have a nice tree-table widget.  It is a bear to 
be wrestled with sooner than later.

One major difference, in Minecraft data, each node is named, and carries 
its type so there is no need to know what the object is.  In that 
example, I can change the color of that map banner from orange to red 
without knowing I'm looking at a map banner.  POV-Ray requires intimate 
knowledge of the structure of each of the main objects to display it in 
a tree.  I don't see me wanting to spend the time decoding how to 
display a RAINBOW_TOKEN.

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[jr] Re: SDL debugging [2279 days 7 hours and 13 minutes ago]

Thu, 16 Jan 2020 08:55:00 GMT

hi,

Dick Balaska <dic### [at] buckosoftcom> wrote:
> I have written an SDL debugger for qtpovray.
> It is still young, but I can set and stop at breakpoints and display the
> values of floats and vectors.

v cool[*].

what plans do you have for dealing with objects and/or object identifiers?

regards, jr.

[*] and a bit envious.  :-)  I shelved some project because I couldn't stomach
the mesh/mesh2 parsing it would need.

[Dick Balaska] SDL debugging [2279 days 10 hours and 10 minutes ago]

Thu, 16 Jan 2020 05:58:04 GMT

I have written an SDL debugger for qtpovray.

It is still young, but I can set and stop at breakpoints and display the 
values of floats and vectors.

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Dick Balaska] qtpovray 3.80.13 [2315 days 11 hours and 16 minutes ago]

Wed, 11 Dec 2019 04:51:56 GMT

https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.13

Bug 25 - Text cursor (I-beam) is invisible after certain keystrokes

-- 
dik
Rendered 49,882,521,600 of 49,882,521,600 pixels (100%)

[Dick Balaska] qtpovray 3.80.11 for Linux [2333 days 7 hours and 42 minutes ago]

Sat, 23 Nov 2019 08:25:33 GMT

https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.11

   * Bug 24 - qtpovray crashes when double-clicking on an error in the 
console

Debian packages have been updated

http://www.buckosoft.com/qtpovray/bugzilla/show_bug.cgi?id=24

-- 
dik
Rendered 26,985,830,400 of 49,882,521,600 pixels (54%)

[Dick Balaska] qtpovray 3.80.10 for Linux [2344 days 1 hour and 28 minutes ago]

Tue, 12 Nov 2019 14:40:14 GMT

https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.10


* Update to POV-Ray Development build v3.8.0-alpha.10064268

Debian packages have been updated.

-- 
dik
Rendered 23,301,043,200 of 40,928,716,800 pixels (56%)

[jr] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2460 days 5 hours and 38 minutes ago]

Fri, 19 Jul 2019 10:30:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I guess I have to read up on exactly what git does and how it works.

there's a free ebook "Pro Git".  https://git-scm.com/book/en/v2


regards, jr.

[Bald Eagle] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2460 days 16 hours and 18 minutes ago]

Thu, 18 Jul 2019 23:50:01 GMT

"Then, to add any of my published
features to the current master, you'd do something like the following
from the master branch in git:

git branch pUltra
git checkout pUltra
git branch --set-upstream-to master pUltra

git pull https://github.com/wfpokorny/povray.git
feature/newDensityPatternInterpolations

git pull https://github.com/wfpokorny/povray.git update/JG_sdl2

git pull . feature/MyVortex    ;# <-- Your Vortex branch.

....

After which you'd do the normal build sequence."

I guess I have to read up on exactly what git does and how it works.
trying
git branch pUltra
or
git pull https://github.com/wfpokorny/povray.git
gave me a "not a git repository" error

I'm assuming it's more complicated than just downloading an extra file or two
before the compiling, since there's stuff that needs to get integrated in
several places.


But I did get hgpovray38 downloaded and installed, so that's a start   :)

[jr] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2460 days 20 hours and 3 minutes ago]

Thu, 18 Jul 2019 20:05:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/15/19 6:28 PM, jr wrote:
> > haven't got the actual url to hand, but for stock POV-Ray, I do the following,
> > as regular user:
> > ...

> I'm partly back from my break away... Always interesting to see how
> others are working and compiling compared to me.

ah, I now wish I'd been more truthful.  :-)  I do the steps outlined up to
running ./configure --help, but from then it's editing a copy of the package
build script of the previous POV-Ray installed, then executing that.

(snipped good stuff on tmpfs)

> - Instead of wget to grab the github zips, I usually just go the to
> github web page for the branch and click the green clone/download button
> which pops up a window with a download zip at the bottom.

I always prefer the .tar.gz archive, when there's a choice.

> - If you'll be running multiple versions of POV-Ray routinely you might
> find installs to unique directories and the wrapper script approach,
> discussed most recently at:
> https://github.com/POV-Ray/povray/issues/374, useful. The build
> processes are today set up to support only one install of a version at a
> time in a target directory. When you run the configure script you can
> specify an install directory in your local space for each compiled 3.8
> version. Individual wrapper scripts then can run each.

thank you for the link, I'll need to think about that tip.  (I currently rename
the executables to their full names and use bash aliases like 'pov371', 'pov38',
and 'pov38x', but that means shared documentation etc)

> Hope my rambling of some help.

sure was.  :-)

regards, jr.

[William F Pokorny] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2461 days 22 hours and 52 minutes ago]

Wed, 17 Jul 2019 17:15:27 GMT

On 7/15/19 6:28 PM, jr wrote:
> hi,
> 
...
> haven't got the actual url to hand, but for stock POV-Ray, I do the following,
> as regular user:
> 
> - make a directory, eg /tmp/P, and cd into it.
> - use 'wget' to retrieve the archive.
> - unpack the archive with 'tar xf filename'.
> - change into the (newly created) povray directory.
> - execute '( cd unix ; ./prebuild.sh)'.  note the parentheses around the
> commands.
> - run './configure', usually first with '--no-create --help' to look see the
> stuff that may need adapting.
> - run 'make'.
> 
> if you capture the whole configuration and compile sequence with something like
> 'typescript(1)', you have a "log" in case of problems.  only actual install
> needs be done with privilege.
> 
>> see:
>> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
>> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
>> https://bitbucket.org/LeForgeron/povray/wiki/Compilation
>>
>> And if there's a way I can start playing with some source code and trying to
>> compile my OWN fork, as a learning experience, then that would be super cool as
>> well.
> 
...
> 
I'm partly back from my break away... Always interesting to see how 
others are working and compiling compared to me. To what jr and Jerome 
have said, I'll somewhat randomly add:

- While /tmp is ramdisk on some systems I don't think this today true 
for Debian based ones like mint - but maybe. You can check with the 'df' 
command which run from an xterm window will spit out a bunch of lines, 
one of which should be something like:

tmpfs            8108248     37556   8070692   1% /tmp

if your /tmp is running on the tmpfs ram disk. If not, it can be changed 
to be so or you can use one of the other ram disk directories which 
typically exist. Look for tmpfs lines in the df output. /run and 
/dev/shm are common user ram disks. I have long used /run/shm/<DirNames> 
on Ubuntu though suppose /run falling out of favor. You should have a 
reasonable amount of ram (min 8GB I'd say) to use ram disk. Use regular 
drives if you know you'll be creating files larger than the free space 
shown by the df command for any tmpfs directory.

- Instead of wget to grab the github zips, I usually just go the to 
github web page for the branch and click the green clone/download button 
which pops up a window with a download zip at the bottom.

- With implementations like the depthmap patch, hgpovray38 or uberpov 
downloading the zip compiling and putting the created 'povray' load 
module somewhere in the executable path with a unique name usually OK 
(uberpov installs apart from povray so make install OK in that case). 
With my other public, routinely re-based to master branches such as:

https://github.com/wfpokorny/povray/tree/update/JG_sdl2

the intent is for users to be set up with git and to be staying current 
with the master development branch. Then, to add any of my published 
features to the current master, you'd do something like the following 
from the master branch in git:

git branch pUltra
git checkout pUltra
git branch --set-upstream-to master pUltra

git pull https://github.com/wfpokorny/povray.git 
feature/newDensityPatternInterpolations

git pull https://github.com/wfpokorny/povray.git update/JG_sdl2

git pull . feature/MyVortex    ;# <-- Your Vortex branch.

...

After which you'd do the normal build sequence. You end up with a 
personal version of POV-Ray with all the additional features you want. 
With my published branches you could download the matching zip and 
compile - but then you'd have only that feature in addition to what's in 
master.

Aside: re-basing branches to master is what I do today and it takes time
on each re-base. My branches not always current with the most recent 
commit. As I write this they are, but - check. The branches I publish 
are today all pull-able / merge-able with master - you can use them all 
at once. Might or might not be true if personal or other's branches are 
pulled too. Modern code control is great, but colliding changes have to 
be sorted out (or avoided) in the end.

- In addition to the packages listed in the <...>/unix/README.md file I 
would also recommend installing sdl2 if you plan to use hgpovray38 or my 
JG_sdl2 patch. I've been running with Jerome's sdl2 update for months 
with good result. If sdl2 not already installed use:

sudo apt-get install libsdl2-dev

Note. Unlike most packages where you don't want to specify the version 
to get the linux package's supported version. It is needed with libsdl2 
due libsdl1.2 being dissimilar to 2.* versions. Install git if you plan 
to roll your own branches or version of POV-Ray.

- Perhaps useful. I use the following (debian) command to check what is 
already installed:

dpkg -l | grep sdl

Which for me shows both libsdl1.2-dev and libsdl2-dev given I run 
versions of POV-Ray using both.

- If you'll be running multiple versions of POV-Ray routinely you might 
find installs to unique directories and the wrapper script approach, 
discussed most recently at: 
https://github.com/POV-Ray/povray/issues/374, useful. The build 
processes are today set up to support only one install of a version at a 
time in a target directory. When you run the configure script you can 
specify an install directory in your local space for each compiled 3.8 
version. Individual wrapper scripts then can run each.

Hope my rambling of some help.

Bill P.

[jr] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2463 days 17 hours and 38 minutes ago]

Mon, 15 Jul 2019 22:30:01 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > confused, is this a povray executable you're talking about?
> Confused about your confusion.
> You are correct - it's the experimental fork referenced in WP's link in the
> initial post.
>
> I'm also keenly interested in installing and experimenting with Jerome
> Grimbert's HgPovRay38 fork, with all of the goodies he's implemented in that.
>
> So, I just want to know that I'm doing the right thing[s] when trying to install
> it, and not mucking up my OS directory with all sorts of cruft that doesn't
> belong there, or doing something stupid whilst in sudo mode.

haven't got the actual url to hand, but for stock POV-Ray, I do the following,
as regular user:

- make a directory, eg /tmp/P, and cd into it.
- use 'wget' to retrieve the archive.
- unpack the archive with 'tar xf filename'.
- change into the (newly created) povray directory.
- execute '( cd unix ; ./prebuild.sh)'.  note the parentheses around the
commands.
- run './configure', usually first with '--no-create --help' to look see the
stuff that may need adapting.
- run 'make'.

if you capture the whole configuration and compile sequence with something like
'typescript(1)', you have a "log" in case of problems.  only actual install
needs be done with privilege.

>
> see:
> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
> https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
> https://bitbucket.org/LeForgeron/povray/wiki/Compilation
>
> And if there's a way I can start playing with some source code and trying to
> compile my OWN fork, as a learning experience, then that would be super cool as
> well.

good luck.  enjoy.


regards, jr.

[Bald Eagle] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2463 days 18 hours and 43 minutes ago]

Mon, 15 Jul 2019 21:25:01 GMT

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

> confused, is this a povray executable you're talking about?

Confused about your confusion.
You are correct - it's the experimental fork referenced in WP's link in the
initial post.

I'm also keenly interested in installing and experimenting with Jerome
Grimbert's HgPovRay38 fork, with all of the goodies he's implemented in that.

So, I just want to know that I'm doing the right thing[s] when trying to install
it, and not mucking up my OS directory with all sorts of cruft that doesn't
belong there, or doing something stupid whilst in sudo mode.

see:
https://github.com/LeForgeron/povray/blob/hgpovray38/unix/install.txt
https://github.com/LeForgeron/povray/blob/hgpovray38/unix/README.md
https://bitbucket.org/LeForgeron/povray/wiki/Compilation

And if there's a way I can start playing with some source code and trying to
compile my OWN fork, as a learning experience, then that would be super cool as
well.

[jr] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2463 days 19 hours and 3 minutes ago]

Mon, 15 Jul 2019 21:05:01 GMT

hi,

no idea about the patch, just a couple of general points.

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Not having really ever compiled much from scratch, perhaps someone can give some
> details about what might seem painfully obvious, but isn't to the uninitiated.
>
> "Download and compile rather than pull probably best. The generated
> povray module should be copied somewhere executable like $HOME/bin and
> renamed pDepth, povrayPGMDepthMap or the like."
>
> What needs to be done first?
> I'm assuming all of that pre-install stuff in the readme.md
>
> Then "download".   OK.  What file - like a filename.tar.z - where best to
> download it TO?  /home/username/downloads?

I tend to use a scratch directory like /tmp/xx/ for downloading + exploring
stuff.  since /tmp/ typically lives in memory, file ops are fast(er).

> But now it has to be extracted...  do this in the downloads directory?
>
> "compile" - I'm assuming this has to do with the "make" instructions - which
> don't make much sense to me at the moment, but maybe the unix/ directory is in
> the extracted directory structure?  As well as the prebuild.sh shell script?

confused, is this a povray executable you're talking about?

> I don't have a $HOME/bin directory - just make one?

yes.  just create one, and add something like the following to your '.bashrc'
file:

export PATH="~/bin:$PATH"

from your next login you'll be able to run any executable stored in '~/bin/'
like any system command.  (your '~/bin/' as first PATH element so you can
override system commands with own, same-named ones).

regards, jr.

[Bald Eagle] Re: POV-Ray v3.8 based unix patch for pgm depth ... [2463 days 20 hours and 3 minutes ago]

Mon, 15 Jul 2019 20:05:00 GMT

Not having really ever compiled much from scratch, perhaps someone can give some
details about what might seem painfully obvious, but isn't to the uninitiated.

"Download and compile rather than pull probably best. The generated
povray module should be copied somewhere executable like $HOME/bin and
renamed pDepth, povrayPGMDepthMap or the like."

What needs to be done first?
I'm assuming all of that pre-install stuff in the readme.md

Then "download".   OK.  What file - like a filename.tar.z - where best to
download it TO?  /home/username/downloads?

But now it has to be extracted...  do this in the downloads directory?

"compile" - I'm assuming this has to do with the "make" instructions - which
don't make much sense to me at the moment, but maybe the unix/ directory is in
the extracted directory structure?  As well as the prebuild.sh shell script?

I don't have a $HOME/bin directory - just make one?  Details for posterity,
please.

Thanks so much   :)


ALSO:
How do I get the files necessary to play with _this_:
http://wiki.povray.org/content/User:Wfpokorny/DensityFile/FillingVolumeWithShapes

[William F Pokorny] Re: Compiling UberPOV on Linux [2507 days 6 hours and 27 minutes ago]

Sun, 2 Jun 2019 09:40:56 GMT

On 6/1/19 5:09 PM, Bill Pragnell wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> The complication in grabbing things out of the main POV-Ray master
>> branch and moving it to UberPOV is the code is in some places
>> significantly different.
> 
> Yes, once I sat down to it, it was evident that the code in those commits you
> linked to mostly isn't in UberPOV. The changes required were much the same
> though, plus a missing iostream equality operator. I fixed it in my local copy,
> and I guess I'll just hang on to that for the time being.
> Thanks for the help!
> 
> Bill P not P
> 
:-) Pleased to hear you worked it out.

Bill P.

[Bill Pragnell] Re: Compiling UberPOV on Linux [2507 days 18 hours and 53 minutes ago]

Sat, 1 Jun 2019 21:15:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> The complication in grabbing things out of the main POV-Ray master
> branch and moving it to UberPOV is the code is in some places
> significantly different.

Yes, once I sat down to it, it was evident that the code in those commits you
linked to mostly isn't in UberPOV. The changes required were much the same
though, plus a missing iostream equality operator. I fixed it in my local copy,
and I guess I'll just hang on to that for the time being.
Thanks for the help!

Bill P not P

[William F Pokorny] Re: Compiling UberPOV on Linux [2510 days 6 hours and 16 minutes ago]

Thu, 30 May 2019 09:51:41 GMT

On 5/30/19 4:58 AM, Bill Pragnell wrote:
> Aha, thanks for that. Those changes are not extensive, I'll just duplicate the
> fix in my local repo. Probably 'easier' than mucking about with boost, from
> where I'm sitting :)
> 
> What's the best way to get those changes into UberPOV permanently? Is it
> possible to do some git magic to cherry pick those commits, or could I just
> apply the fix on an UberPOV branch and push it myself?
> 
> Bill
> 
> (maybe I should start signing off as Bill P just to confuse everyone :D)
> 

Christoph is the only one who can update UberPOV and he's not worked 
there in a long time.

There is a git cherry picking technique. I used exactly once years ago - 
meaning I don't remember how to do it! Search for 'git cherry pick'.

The complication in grabbing things out of the main POV-Ray master 
branch and moving it to UberPOV is the code is in some places 
significantly different. I think this a reason why UberPOV didn't take 
hold as a general test bed for things. I moved one branch to UberPOV 
(never merged) and it collided with UberPOV changes. It meant a lot of 
work which I only ever really made sure compiled - I didn't test the 
features again as part of UberPOV. Also found myself with two branches 
of the same feature. One off POV-Ray master and another off UberPOV. Too 
much work.

If you want to run UberPOV specifically I'd recommend creating a branch 
and just letting it sit there. If it's your only UberPOV branch, compile 
and run that branch. If you end up with >1 let the branches, pull each 
all into an 'UberBillP' branch off the UberPOV master branch and compile.

The last is what I've been doing. Several times a year I build a version 
with the features I want off the current POV-Ray master. Down side is 
it's getting to be a lot of branches to rebase/merge when the master 
branch changes. I'm not a git expert. Perhaps there are better ways.

Bill P.

[Bill Pragnell] Re: Compiling UberPOV on Linux [2510 days 7 hours and 8 minutes ago]

Thu, 30 May 2019 09:00:00 GMT

Aha, thanks for that. Those changes are not extensive, I'll just duplicate the
fix in my local repo. Probably 'easier' than mucking about with boost, from
where I'm sitting :)

What's the best way to get those changes into UberPOV permanently? Is it
possible to do some git magic to cherry pick those commits, or could I just
apply the fix on an UberPOV branch and push it myself?

Bill

(maybe I should start signing off as Bill P just to confuse everyone :D)

[William F Pokorny] Re: Compiling UberPOV on Linux [2510 days 7 hours and 45 minutes ago]

Thu, 30 May 2019 08:22:50 GMT

On 5/29/19 6:42 PM, Bill Pragnell wrote:
> Hi all
> 
> Been tinkering with UberPOV on Mac for a while (thanks Yvo!) and I find myself
> wanting to also use it on a recent install of Linux Mint. So I cloned it from
> github and followed the unix build instructions, only to find that
> boost/tr1/memory.hpp cannot be found. Some closer investigation reveals that my
> version of boost is 1.65.1, but the TR1 stuff was removed in 1.65.0.
> 
> Has anyone else encountered this? Is there an easier way to solve this than
> rolling back my boost version?
> 
> Bill
> 

My recollection is that something promised with respect to how headers 
would be changed when the boost feature moved into C++ didn't happen as
expected.

There was discussion of the issue at:

https://github.com/POV-Ray/povray/pull/42

and

http://news.povray.org/povray.general/thread/%3C5a233b19%241%40news.povray.org%3E/

Christoph fixed the issue while looking at:

https://github.com/POV-Ray/povray/issues/317

and it looks like the fix took two commits:

https://github.com/POV-Ray/povray/commit/1dbca0bad858f5605cc8e3a2629eb0e0dbfbb052

and

https://github.com/POV-Ray/povray/commit/a847cb72563f9d9d072ff2f9ef5300b91c8b5839

Perhaps you can steal from some of that work. I'm not aware of anything 
'easy,' so to speak, with respect to a fix.

Bill P. (The other...)

[Bill Pragnell] Compiling UberPOV on Linux [2510 days 17 hours and 23 minutes ago]

Wed, 29 May 2019 22:45:01 GMT

Hi all

Been tinkering with UberPOV on Mac for a while (thanks Yvo!) and I find myself
wanting to also use it on a recent install of Linux Mint. So I cloned it from
github and followed the unix build instructions, only to find that
boost/tr1/memory.hpp cannot be found. Some closer investigation reveals that my
version of boost is 1.65.1, but the TR1 stuff was removed in 1.65.0.

Has anyone else encountered this? Is there an easier way to solve this than
rolling back my boost version?

Bill

[William F Pokorny] POV-Ray v3.8 based unix patch for pgm depth maps. [2523 days 23 hours and 4 minutes ago]

Thu, 16 May 2019 17:03:52 GMT

It recently hit me some of the solver related debug output I was 
creating was not too far from providing a decent depth map output. Given 
depth maps are a frequently requested feature, a *nix only stand alone 
version of POV-Ray specifically modified to create depth map output 
based on the current v3.8 master can be had at:

https://github.com/wfpokorny/povray/tree/independent/PGMimageDepthMap

Download and compile rather than pull probably best. The generated 
povray module should be copied somewhere executable like $HOME/bin and 
renamed pDepth, povrayPGMDepthMap or the like.

No scene modifications are needed, but turnig off photons and radiosity 
will help performance. This version of POV-Ray itself hard coded to run 
a pixel at a time with options creating additional camera rays like AA 
and focal blur hard coded off. Output is always to a file called 
depth.pgm in plain text format and linear values normalized to a range. 
Option SDL variables and defaults are:

DepthMapMin           = 0.0;
DepthMapMax           = 1000.0;
DepthMapPGMDepth      = 65535.0;
DepthMapRangeXVal     = 0.0;
DepthMapComments      = 0.0;   (*) - Float depth from ray origin.
DepthMapIntersections = 0.0;   (*) - Where intersections in range.
DepthMapNormals       = 0.0;   (*) - Raw shape normal at intersection.
DepthMapRayOrigins    = 0.0;
DepthMapRayDirections = 0.0;

These options can be set with the existing Declare=<var_name>=<float> 
command line mechanism. For example, the sample balcony.pov and 
woodbox.pov scenes in the image posted to povray.binaries.images were 
rendered with:

pDepth +W450 +h600 balcony.pov Declare=DepthMapMin=0 Declare=DepthMapMax=800

and

pDepth +W800 +h600 woodbox.pov Declare=DepthMapMin=10 
Declare=DepthMapMax=50 \
    Declare=DepthMapPGMDepth=15

If you turn on comments these get added to the pgm file. 
DepthMapComments must be on (not 0.0) to get other information. So the 
command:

pDepth +W400 +h300 woodbox.pov Declare=DepthMapMin=10 
Declare=DepthMapMax=50 \
        Declare=DepthMapComments=1 \
        Declare=DepthMapIntersections=1 Declare=DepthMapNormals=1

creates an ascii pgm file where the first lines look like:

P2
400
300
65535
# DepthMapMin = 10.000  DepthMapMax = 50.000  for mapped range of = 40.000
51196  # 41.2482798167746 I=<-7.6527354,6.4294999e-17,24.929733> N=<0,1,0>
51151  # 41.2204724321481 I=<-7.5807234,-8.7917847e-17,24.905729> N=<0,1,0>
... and so on

There is a significant performance hit given this feature is hanging on 
a debug mechanism. Strongly recommend running on a ramdisk as the file 
I/O opens and closes the file on every string write. Further files can 
get really large depending upon selected output.

---- Performance woodbox.pov with v3.8 master 400 x 300 no AA
Original scene on my 2 core 4 thread i3: 1.22s

---- Performance hit with pDepth
Blocksize 1x1 with 1 thread:             3.98s
Creating depth map pgm no comments       5.82s
Comments on. Ray origins and directions  7.96s

Note. POV-Ray itself fails on image read when the comments are present 
in the output depth.pgm. All the other programs I've tried work OK - 
including netpbm programs. To the netpbm site documents on file formats, 
I think POV-Ray correct. It's just not what netpbm itself actually does 
for the plain ascii format. Run without comments if using the depth.pgm 
directly as input to POV-Ray.

To view pgm bit depths >255 (ie using 16 bit channel) on a srgb-ish 
display environment correctly you may need to use POV-Ray itself. The 
programs I most frequently use for viewing seem to be mapping internally 
to 0-255 channel ranges. I see more banding with 16 bit channel outputs 
than should be. A small scene file which can be used for viewing 16 bit 
pgm output with POV-Ray follows. The view is gamma corrected one of the 
linear depth.pgm. Specifying proportionally matching width and height to 
the depth.pgm file, use your normal version of POV-Ray as in:

povray asPGMViewer.pov +p

Bill P.

//------------- Start asPGMViewer.pov
#version 3.8;
// Scene using POV-Ray as linear pgm file srgb-viewer.
// Use +w +h values which match pgm file's.
global_settings { assumed_gamma 1 }
#declare Grey20 = srgb <0.2,0.2,0.2>;
background { color Grey20 }
#declare VarOrthoMult = 
1.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 FileName = "depth.pgm"
#declare ImageMap00_P = pigment { image_map { FileName gamma 1 
interpolate 2 }};
#declare ImageMap00_Range = max_extent(ImageMap00_P);
#declare ImageMap00_NrmScale =
     <min(1,ImageMap00_Range.x/ImageMap00_Range.y),
      min(1,ImageMap00_Range.y/ImageMap00_Range.x),1>;
#declare Finish00 = finish { ambient rgb 1 }
#declare Pigment00 = pigment {
     image_map { FileName
         gamma 1
         premultiplied off
         map_type 0
         once
         interpolate 2
     }
}
#declare Texture00 = texture {
     pigment { Pigment00 }
     finish { Finish00 }
}
#declare Box00 = box { <0,0,0>,<1,1,1> }
#declare Object00 = object {
     Box00
     texture { Texture00 }
     translate <-0.5,-0.5,0>
     scale ImageMap00_NrmScale
}

//--- scene ---
    camera { Camera01z }
    object { Object00 }

//------------- end asPGMViewer.pov

[dick balaska] qtpovray v3.80.9 for Linux [2742 days 12 hours and 9 minutes ago]

Wed, 10 Oct 2018 03:58:59 GMT

qtpovray (3.80.9~xenial1) xenial; urgency=low

  * Update to POV-Ray Development build v3.8.0-alpha.9861167+av620

 -- Dick Balaska <dic### [at] buckosoftcom>  Tue, 09 Oct 2018 23:31:27 -0400



https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.9
https://launchpad.net/~qtpovray/+archive/ubuntu/qtpovray

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[dick balaska] Re: qtpovray v3.80.8 for Linux [2760 days 19 hours and 19 minutes ago]

Fri, 21 Sep 2018 20:48:31 GMT

On 09/21/2018 03:35 AM, Mike Horvath wrote:
> On 9/20/2018 11:27 PM, dick balaska wrote:
>> qtpovray (3.80.8~xenial1) xenial; urgency=low
> 
> Do you plan to port the qt frontend to Windows?

Yes.  In fact, the frontend works on Windows. ;)
My first foray was "qtpov", a Qt gui that launched a custom povray that
used websockets instead of a command line. That ran on Windows and
Linux.  That gui is the qtpovray frontend.

My problem is with building povray with qmake (Qt's ./configure
replacement).  It all works great on Linux, but, on Windows, I have a
problem with a master project that has two library subprojects plus an
executable subproject.  (It tries to build the second library skipping
the "compile the source" bits, thus tipping over because the .obj files
don't exist).  I'll get to it at some point.

My Windows experience these days is limited to a 1024x768 window in my
Linux desktop.  VS2015 and QtCreator are pretty laughable at that size.
Ain't nobody wanna deal with that.
> 
> 
> Mike

-- 
dik
Rendered 1024 of 921600 pixels (0%)

[Mike Horvath] Re: qtpovray v3.80.8 for Linux [2761 days 8 hours and 33 minutes ago]

Fri, 21 Sep 2018 07:35:01 GMT

On 9/20/2018 11:27 PM, dick balaska wrote:
> qtpovray (3.80.8~xenial1) xenial; urgency=low
> 
>    * Bug 20 - Add a Font chooser to select the console font
>      http://www.buckosoft.com/qtpovray/configEditor.html
> 
>    * Bug 21 - Add a user configured Insert Menu to be merged with
>      the system Insert Menu.
>      http://www.buckosoft.com/qtpovray/userInsertMenu.html
> 
>   -- Dick Balaska <dic### [at] buckosoftcom>  Thu, 20 Sep 2018 19:19:00 -0400
> 
> 
> 
> 


Do you plan to port the qt frontend to Windows?


Mike

[dick balaska] qtpovray v3.80.8 for Linux [2761 days 12 hours and 40 minutes ago]

Fri, 21 Sep 2018 03:27:46 GMT

qtpovray (3.80.8~xenial1) xenial; urgency=low

  * Bug 20 - Add a Font chooser to select the console font
    http://www.buckosoft.com/qtpovray/configEditor.html

  * Bug 21 - Add a user configured Insert Menu to be merged with
    the system Insert Menu.
    http://www.buckosoft.com/qtpovray/userInsertMenu.html

 -- Dick Balaska <dic### [at] buckosoftcom>  Thu, 20 Sep 2018 19:19:00 -0400




-- 
dik
Rendered 1024 of 921600 pixels (0%)

[jr] Re: Hgpovray38, current state [2769 days and 28 minutes ago]

Thu, 13 Sep 2018 15:40:00 GMT

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 13.09.2018 um 11:29 schrieb jr:
> > Le Forgeron <jgr### [at] freefr> wrote:
> >> Le 12/09/2018 ÃƒÂ  23:50, jr a
ÃƒÂ©critÃ‚Â :
> >>> downloaded the .tar.gz version and run into trouble -- make error when
> >>> compilation gets to the maths/spline code.  log posted in p.binaries.misc.
> >> What age is your compiler ?
> > 4.8.2.  :-)
>
> For the records, GCC 4.8.2 is feature-complete with respect to C++11.
> ...
> Case in point: gcc 4.8.2 (or, more precisely, the standard header files
> that came with it), despite claiming full C++11 compliance, actually
> isn't, due to a couple of bugs in the implementation of std::vector<T>.
>
> And that seems to be exactly what you are seeing; I couldn't find a bug
> report matching the /exact/ symptoms, but the error messages point to a
> a non-standard-compliant interface of `std::vector<T>::insert`, and
> there are bug reports of multiple other non-compliances of
> `std::vector<T>`, such as this one:
>
>     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55817
>
> Judging from when the other bugs were fixed, you'll probably need gcc
> 4.9 or later.

wow.  thank you very much for digging in to the details, appreciated.  update it
is then (well, near future :-))


regards, jr.

[clipka] Re: Hgpovray38, current state [2769 days 1 hour and 51 minutes ago]

Thu, 13 Sep 2018 14:16:41 GMT

Am 13.09.2018 um 11:29 schrieb jr:
> hi,
> 
> Le Forgeron <jgr### [at] freefr> wrote:
>> Le 12/09/2018 ÃƒÂ  23:50, jr a
ÃƒÂ©critÃ‚Â :
>>> downloaded the .tar.gz version and run into trouble -- make error when
>>> compilation gets to the maths/spline code.  log posted in p.binaries.misc.
>>
>> What age is your compiler ?
> 
> 4.8.2.  :-)

For the records, GCC 4.8.2 is feature-complete with respect to C++11.

> however, is that not a "red herring"?  I would expect './configure' to fail if
> the s/ware is .. not modern enough.

The question isn't that offbeat; as a matter of fact, the only reliable
way to test whether any given compiler will compile a given program is
to actually try compiling that program.

Case in point: gcc 4.8.2 (or, more precisely, the standard header files
that came with it), despite claiming full C++11 compliance, actually
isn't, due to a couple of bugs in the implementation of std::vector<T>.

And that seems to be exactly what you are seeing; I couldn't find a bug
report matching the /exact/ symptoms, but the error messages point to a
a non-standard-compliant interface of `std::vector<T>::insert`, and
there are bug reports of multiple other non-compliances of
`std::vector<T>`, such as this one:

    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55817

Judging from when the other bugs were fixed, you'll probably need gcc
4.9 or later.

[jr] Re: Hgpovray38, current state [2769 days 6 hours and 38 minutes ago]

Thu, 13 Sep 2018 09:30:00 GMT

hi,

Le Forgeron <jgr### [at] freefr> wrote:
> Le 12/09/2018 Ã  23:50, jr a Ã©critÂ :
> > downloaded the .tar.gz version and run into trouble -- make error when
> > compilation gets to the maths/spline code.  log posted in p.binaries.misc.
>
> What age is your compiler ?

4.8.2.  :-)

however, is that not a "red herring"?  I would expect './configure' to fail if
the s/ware is .. not modern enough.

> I have compiled it with g++ 7, modern clang and icc (intel).



regards, jr.

[Le Forgeron] Re: Hgpovray38, current state [2769 days 10 hours and 26 minutes ago]

Thu, 13 Sep 2018 05:42:00 GMT

Le 12/09/2018 Ã  23:50, jr a Ã©critÂ :
> hi,
> 
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 18/08/2018 ÃƒÂ  13:58, Le_Forgeron a
ÃƒÂ©critÃ‚Â :
>>> For the people who do not want to bother with git, Hgpovray is now
>>> available as sources
>> Latest version so far:
> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade
> 
> downloaded the .tar.gz version and run into trouble -- make error when
> compilation gets to the maths/spline code.  log posted in p.binaries.misc.

What age is your compiler ?

I have compiled it with g++ 7, modern clang and icc (intel).

[jr] Re: Hgpovray38, current state [2769 days 18 hours and 13 minutes ago]

Wed, 12 Sep 2018 21:55:01 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 18/08/2018 Ã  13:58, Le_Forgeron a Ã©critÂ :
> > For the people who do not want to bother with git, Hgpovray is now
> > available as sources
> Latest version so far:
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade

downloaded the .tar.gz version and run into trouble -- make error when
compilation gets to the maths/spline code.  log posted in p.binaries.misc.

regards, jr.

[Le Forgeron] Re: Hgpovray38, current state [2769 days 19 hours and 29 minutes ago]

Wed, 12 Sep 2018 20:39:04 GMT

Le 18/08/2018 Ã  13:58, Le_Forgeron a Ã©critÂ :
> For the people who do not want to bother with git, Hgpovray is now
> available as sources
> 
> 
Latest version so far:

https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade

> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226.Bigarade


> More works on the agenda :
> 
> http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38
>

[dick balaska] qtpovray v3.80.7 for Linux [2783 days 7 hours and 36 minutes ago]

Thu, 30 Aug 2018 08:32:10 GMT

* Bug 18 - Add a Font chooser to select the editor font
  * Bug 16 - Install the fonts that qtpovray uses
  * Bug 17 - Update to POV-Ray 3.8.0-alpha.9811560

If you did the ubuntu/ppa install thingy, then you should automatically
pick up the new version.

http://www.buckosoft.com/qtpovray/
https://launchpad.net/~qtpovray/+archive/ubuntu/qtpovray
https://github.com/dickbalaska/qtpovray/releases/tag/v3.80.7
-- 
dik
Rendered 1024 of 921600 pixels (0%)

[Le Forgeron] Hgpovray38, current state [2795 days 4 hours and 9 minutes ago]

Sat, 18 Aug 2018 11:58:25 GMT

For the people who do not want to bother with git, Hgpovray is now
available as sources


https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30

> https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.226-Thermidor-30

More works on the agenda :

http://wiki.povray.org/content/User:Le_Forgeron/HgPovray38

[And] Re: Blurred reflections [2825 days 1 hour and 38 minutes ago]

Thu, 19 Jul 2018 14:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 18.07.2018 um 08:03 schrieb And:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 16.07.2018 um 16:10 schrieb And:
> >>> Will blurred reflection integrate into official version one day? (this function
> >>> is too important)
> >>
> >> One could argue that "too important" also means "too important to screw up".
> >>
> >> So the answer to your question may depend on whether a sufficiently good
> >> and robust implementation (including a sufficiently good syntax and all)
> >> can be... well, implemented.
> >>
> >> My gut feeling is that the answer is "yes".
> >
> > Well
> > But what is the disadvantage with recently implement?
>
> If you want my opinion: Speed.
>
> Blurred reflections work best when the render engine includes a good
> framework for unbiased stochastic rendering, so that all oversampling
> stuff -- blurred reflections, area lights, media, focal blur and
> what-have-you-not -- don't cause the render time to explode exponentially.
>

Yeah... indeed. Unbiased stochastic rendering grew rapidly (and showed its
advantage) during this ten years.

> POV-Ray does not have any such framework. UberPOV does, but it is still
> rudimentary and probably needs lots more work.

[clipka] Re: Blurred reflections [2826 days 2 hours and 36 minutes ago]

Wed, 18 Jul 2018 13:31:44 GMT

Am 18.07.2018 um 08:03 schrieb And:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 16.07.2018 um 16:10 schrieb And:
>>> Will blurred reflection integrate into official version one day? (this function
>>> is too important)
>>
>> One could argue that "too important" also means "too important to screw up".
>>
>> So the answer to your question may depend on whether a sufficiently good
>> and robust implementation (including a sufficiently good syntax and all)
>> can be... well, implemented.
>>
>> My gut feeling is that the answer is "yes".
> 
> Well
> But what is the disadvantage with recently implement?

If you want my opinion: Speed.

Blurred reflections work best when the render engine includes a good
framework for unbiased stochastic rendering, so that all oversampling
stuff -- blurred reflections, area lights, media, focal blur and
what-have-you-not -- don't cause the render time to explode exponentially.

POV-Ray does not have any such framework. UberPOV does, but it is still
rudimentary and probably needs lots more work.

[And] Re: Blurred reflections [2826 days 10 hours and 3 minutes ago]

Wed, 18 Jul 2018 06:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 16.07.2018 um 16:10 schrieb And:
> > Will blurred reflection integrate into official version one day? (this function
> > is too important)
>
> One could argue that "too important" also means "too important to screw up".
>
> So the answer to your question may depend on whether a sufficiently good
> and robust implementation (including a sufficiently good syntax and all)
> can be... well, implemented.
>
> My gut feeling is that the answer is "yes".

Well
But what is the disadvantage with recently implement?

[clipka] Re: Blurred reflections [2828 days 1 hour and 33 minutes ago]

Mon, 16 Jul 2018 14:34:45 GMT

Am 16.07.2018 um 16:10 schrieb And:
> Will blurred reflection integrate into official version one day? (this function
> is too important)

One could argue that "too important" also means "too important to screw up".

So the answer to your question may depend on whether a sufficiently good
and robust implementation (including a sufficiently good syntax and all)
can be... well, implemented.

My gut feeling is that the answer is "yes".

[And] Re: Blurred reflections [2828 days 1 hour and 53 minutes ago]

Mon, 16 Jul 2018 14:15:00 GMT

Will blurred reflection integrate into official version one day? (this function
is too important)

[William F Pokorny] Re: media method 3 jitter 0 performance branch o... [2928 days 7 hours and 58 minutes ago]

Sat, 7 Apr 2018 08:09:50 GMT

On 04/06/2018 01:44 PM, clipka wrote:
> Sorry, I'm a bit late in replying to this one.
> 
> Am 18.02.2018 um 16:40 schrieb William F Pokorny:
> 
                                  s
>> Note: I recommend jitter alway  be 0 given our current implementation
>> unless a noisy, expensive to AA result is what you want.
> 
> I'm a bit reluctant to throw jitter overboard entirely (even for an
> individual sampling method, particularly the default one). 

Agree given it already exists as is and folks have likely used it in 
scenes. I have it still in my sandbox media branches.

> When a scene
> contains other sources of image noise anyway (such as subsurface light
> transport, jittered area lights, blurred reflections or focal blur),
> increasing media jitter may actually be a better choice performance-wise
> than cranking up the media sampling quality parameters.
> 

If rendering a non-uniform density accurately is your aim, I don't agree 
with the last of this sentence for method 3 jitter. Method 3 jitter is 
expensive noise.

Jitter tends to help 'resolve non-unform media densities' with methods 1 
& 2. Jitter often helps as an option implemented in other than media. In 
those cases jitter amounts to less uniform sampling toward a still 
accurate result. In method 3, jitter - as implemented today - acts 
against the sampling approach even aside from github issue(s): 
https://github.com/POV-Ray/povray/issues/348.

Elsewhere - or maybe only as a thought floating about my head - I've 
suggested a new method 3 aa_jitter feature might be useful. This a 
jitter with an effect more in line with jitter in the other two media 
methods. I wouldn't be free to method 3 performance of course...

Bill P.

[clipka] Re: media method 3 jitter 0 performance branch o... [2928 days 22 hours and 23 minutes ago]

Fri, 6 Apr 2018 17:44:48 GMT

Sorry, I'm a bit late in replying to this one.

Am 18.02.2018 um 16:40 schrieb William F Pokorny:

> Note: I recommend jitter alway be 0 given our current implementation
> unless a noisy, expensive to AA result is what you want.

I'm a bit reluctant to throw jitter overboard entirely (even for an
individual sampling method, particularly the default one). When a scene
contains other sources of image noise anyway (such as subsurface light
transport, jittered area lights, blurred reflections or focal blur),
increasing media jitter may actually be a better choice performance-wise
than cranking up the media sampling quality parameters.

[William F Pokorny] media method 3 jitter 0 performance branch off r... [2976 days and 27 minutes ago]

Sun, 18 Feb 2018 15:40:30 GMT

For those building their own POV-Ray versions see:

https://github.com/wfpokorny/povray/tree/tune/mediaPerformanceAndSceneFiles

I'm working on other more complicated, longer term alternatives, but the 
commit for the scene changes and the commit for method 3 performance 
contained in this branch are simple, safe and reasonably well tested. 
Enough so that I think it worth considering this branch for adoption in 
release/v3.8.0. Opinions?

Bill P.

--- Details for those interested ---
For the usual Jitter=0 media the performance gain tops out at about 
5.5%. For (abs(Jitter))!=0 there the penalty for the conditional tops 
out at a performance loss of 1.5%.  Not possible at this point, but if 
we could dump the jitter option with method 3 we'd top out at a 7% 
performance gain for complex medias/densities.

Note: I recommend jitter alway be 0 given our current implementation 
unless a noisy, expensive to AA result is what you want.

Note: Performance is always better in my testing where method 3 is 
really used however many of our sample scenes will see less performance 
gain (1-1.5%) because they almost all use constant media (PLAIN_PATTERN 
densities) and so trigger a fast path into method 1 for part of the 
media evaluation. In other words many of our sample scenes partly bypass 
the method 3 code and so the change herein.

While I reformatted the functions 
MediaFunction::ComputeMediaAdaptiveSampling and 
MediaFunction::ComputeOneMediaSampleRecursive to the 120 character max, 
the code change for performance is quite small. Instead of doing the 
jitter calculattion on all ComputeOneMediaSample() calls it changes that 
parameter to:

(IMedia->Jitter==0.0 ? 0.0 : dd * IMedia->Jitter * 
(randomNumberGenerator() - 0.5))

or similar.  In addition the top of ComputeOneMediaSampleRecursive the 
jdist calc becomes:

     if(Jitter==0.0)
         jdist = d2;
     else
         jdist = d2 + Jitter * (d3 - d1) * (randomNumberGenerator() - 0.5);


Aside: It neatly happens the performance improvement here speeds up our 
benchmark scene in my testing almost enough to counter the 
FixedSimpleVector elimination degrade.

--- Scene file changes. Both fix artifacts/bugs/set-up issues.

1) media3.pov - Result looked really bad with existing samples setting 
so increased it until result looked good.

2) micro.pov - Was using "intervals 2" to no benefit.  It was also using 
an assumed_gamma of 1.5.  Changed that to 1.0 and updated the emitting 
media colors for I believe is a much better result.  The exact result 
here not mattering much in any case as just demonstrating technique.

[Kenneth] Re: Blurred reflections [2983 days 18 hours and 38 minutes ago]

Sat, 10 Feb 2018 21:30:00 GMT

Alain <kua### [at] videotronca> wrote:
> Le 18-02-10 Ã  02:59, Kenneth a Ã©critÂ :

> >
> > I didn't know that reflection would 'borrow' the specular's metallic
> > in such a
> > case. Thanks.

>
> It's a leftover/backware compatibility thing.
> Before the reflection block was introduced, there was no way to know if
> any metallic modifier was intended for phong, specular or reflection.
>

Ah. That explains the 'mystery' I used to wonder about in the older 3.6.x days--
I could never figure out exactly what was going on with metallic. Thanks!
Mystery solved ;-)

[Alain] Re: Blurred reflections [2983 days 22 hours and 44 minutes ago]

Sat, 10 Feb 2018 17:24:15 GMT

Le 18-02-10 Ã  02:59, Kenneth a Ã©critÂ :
> Alain <kua### [at] videotronca> wrote:
> 
> 
>> Reflection may be used without a block which is the legacy syntax. In
>> that case, it will borrow the metallic of specular, but not the roughness.
> 
> I didn't know that reflection would 'borrow' the specular's metallic in such a
> case. Thanks.
> 
> 
> 
> 

It's a leftover/backware compatibility thing.
Before the reflection block was introduced, there was no way to know if 
any metallic modifier was intended for phong, specular or reflection. 
Also, the actual order was totally ignored.

Thus
metallic
phong 1
phong_size 150
reflection 0.8

phong 1
metallic
phong_size 150
reflection 0.8

phong 1
reflection 0.8
metallic
phong_size 150

phong_size 150
metallic
reflection 0.8
phong 1

and

phong 1
phong_size 150
reflection 0.8
metallic

would gives the same result.
This is what I mean by "borrow".

[Kenneth] Re: Blurred reflections [2984 days 8 hours and 3 minutes ago]

Sat, 10 Feb 2018 08:05:03 GMT

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


> Reflection may be used without a block which is the legacy syntax. In
> that case, it will borrow the metallic of specular, but not the roughness.

I didn't know that reflection would 'borrow' the specular's metallic in such a
case. Thanks.

[Mike Horvath] Re: Blurred reflections [2984 days 13 hours and 46 minutes ago]

Sat, 10 Feb 2018 02:22:13 GMT

On 2/9/2018 8:23 PM, Alain wrote:
> This way :
> #local ldrawChromeFin=finish {
>  Â brilliance 6
>  Â diffuse 0.7
>  Â metallic
>  Â specular 0.80 roughness 1/120
>  Â reflection {0.8 roughness 1/120 metallic}
> }
> 
> The first metallic affect the specular or phong highlight. The metallic 
> in the reflection block affect the reflection only.
> There is NO specular block.
> Reflection may be used without a block which is the legacy syntax. In 
> that case, it will borrow the metallic of specular, but not the roughness.
> 

Awesome, thanks. That clears up the syntax for me.


Mike

[Alain] Re: Blurred reflections [2984 days 14 hours and 45 minutes ago]

Sat, 10 Feb 2018 01:22:37 GMT

Le 18-02-09 Ã  07:19, Mike Horvath a Ã©critÂ :
> On 2/6/2018 7:22 PM, Alain wrote:
>> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>>> How do I get blurred reflections working in UberPOV? I had it working 
>>> a few years go, but have since forgotten how. Thanks.
>>>
>>>
>>> Mike
>>
>> You only need to add roughness into the reflection block such as :
>>
>> reflection{0.9 metallic roughness 0.001}
>> or
>> reflection{1 fresnel roughness 0.001}
>> or
>> reflection{0.8 roughness 0.001}
>> or
>> reflection{0.1, 1 roughness 0.001}
>>
>> Normally, you also want to add specular highlights with the same 
>> roughness amount.
> 
> What would the correct way to update the following be?
> 
> 
> #local ldrawChromeFin=finish {
>  Â brilliance 6
>  Â diffuse 0.7
>  Â metallic
>  Â specular 0.80
>  Â roughness 1/120
>  Â reflection 0.8
> };
> 
> 
> 
> Do reflection and specular each have their own blocks containing a 
> roughness parameter?
> 
> 
> #local ldrawChromeFin=finish {
>  Â brilliance 6
>  Â diffuse 0.7
>  Â metallic
>  Â specular {0.80 roughness 1/120}
>  Â reflection {0.8 roughness 1/120}
> };
This could cause an error message.
> 
> 
> 
> Mike

This way :
#local ldrawChromeFin=finish {
  brilliance 6
  diffuse 0.7
  metallic
  specular 0.80 roughness 1/120
  reflection {0.8 roughness 1/120 metallic}
}

The first metallic affect the specular or phong highlight. The metallic 
in the reflection block affect the reflection only.
There is NO specular block.
Reflection may be used without a block which is the legacy syntax. In 
that case, it will borrow the metallic of specular, but not the roughness.

[Alain] Re: Blurred reflections [2984 days 14 hours and 55 minutes ago]

Sat, 10 Feb 2018 01:12:32 GMT

Le 18-02-09 Ã  07:16, Mike Horvath a Ã©critÂ :
> On 2/6/2018 7:22 PM, Alain wrote:
>> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>>> How do I get blurred reflections working in UberPOV? I had it working 
>>> a few years go, but have since forgotten how. Thanks.
>>>
>>>
>>> Mike
>>
>> You only need to add roughness into the reflection block such as :
>>
>> reflection{0.9 metallic roughness 0.001}
>> or
>> reflection{1 fresnel roughness 0.001}
>> or
>> reflection{0.8 roughness 0.001}
>> or
>> reflection{0.1, 1 roughness 0.001}
>>
>> Normally, you also want to add specular highlights with the same 
>> roughness amount.
> 
> How do I set the roughness of a specular highlight?
> Is there a `specular {}` block?
> 
> 
> Mike

finish{
	diffuse 0.1
	ambient 0
	reflection{1 fresnel roughness 0.001 conserve_energy}
	specular 0.7
	roughness 0.001
   }

It have been around like that for almost for ever...

[Mike Horvath] Re: Blurred reflections [2985 days 3 hours and 29 minutes ago]

Fri, 9 Feb 2018 12:39:03 GMT

On 2/9/2018 7:19 AM, Mike Horvath wrote:
> On 2/6/2018 7:22 PM, Alain wrote:
>> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>>> How do I get blurred reflections working in UberPOV? I had it working 
>>> a few years go, but have since forgotten how. Thanks.
>>>
>>>
>>> Mike
>>
>> You only need to add roughness into the reflection block such as :
>>
>> reflection{0.9 metallic roughness 0.001}
>> or
>> reflection{1 fresnel roughness 0.001}
>> or
>> reflection{0.8 roughness 0.001}
>> or
>> reflection{0.1, 1 roughness 0.001}
>>
>> Normally, you also want to add specular highlights with the same 
>> roughness amount.
> 
> What would the correct way to update the following be?
> 
> 
> #local ldrawChromeFin=finish {
>  Â brilliance 6
>  Â diffuse 0.7
>  Â metallic
>  Â specular 0.80
>  Â roughness 1/120
>  Â reflection 0.8
> };
> 
> 
> 
> Do reflection and specular each have their own blocks containing a 
> roughness parameter?
> 
> 
> #local ldrawChromeFin=finish {
>  Â brilliance 6
>  Â diffuse 0.7
>  Â metallic
>  Â specular {0.80 roughness 1/120}
>  Â reflection {0.8 roughness 1/120}
> };
> 
> 
> 
> Mike


Ignore the `metallic` keyword there since I overlooked it too.


Mike

[Thomas de Groot] Re: Blurred reflections [2985 days 3 hours and 33 minutes ago]

Fri, 9 Feb 2018 12:35:01 GMT

On 8-2-2018 22:44, Alain wrote:
> Le 18-02-06 Ã  20:10, Mike Horvath a Ã©critÂ :
>> On 2/6/2018 7:22 PM, Alain wrote:
>>> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>>>> How do I get blurred reflections working in UberPOV? I had it 
>>>> working a few years go, but have since forgotten how. Thanks.
>>>>
>>>>
>>>> Mike
>>>
>>> You only need to add roughness into the reflection block such as :
>>>
>>> reflection{0.9 metallic roughness 0.001}
>>> or
>>> reflection{1 fresnel roughness 0.001}
>>> or
>>> reflection{0.8 roughness 0.001}
>>> or
>>> reflection{0.1, 1 roughness 0.001}
>>>
>>> Normally, you also want to add specular highlights with the same 
>>> roughness amount.
>>
>> Thanks! What do I use in the header?
>>
>> One of my old scenes uses this:
>>
>> #version unofficial patch 3.71;
>> #patch 0.99;
>>
>> But I don't know if that's up-to-date.
>>
>>
>> Mike
> 
> No longer needed.

Oh? I had not been aware of that. Good to know; thanks.

-- 
Thomas

[Mike Horvath] Re: Blurred reflections [2985 days 3 hours and 49 minutes ago]

Fri, 9 Feb 2018 12:18:39 GMT

On 2/6/2018 7:22 PM, Alain wrote:
> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>> How do I get blurred reflections working in UberPOV? I had it working 
>> a few years go, but have since forgotten how. Thanks.
>>
>>
>> Mike
> 
> You only need to add roughness into the reflection block such as :
> 
> reflection{0.9 metallic roughness 0.001}
> or
> reflection{1 fresnel roughness 0.001}
> or
> reflection{0.8 roughness 0.001}
> or
> reflection{0.1, 1 roughness 0.001}
> 
> Normally, you also want to add specular highlights with the same 
> roughness amount.

What would the correct way to update the following be?


#local ldrawChromeFin=finish {
  brilliance 6
  diffuse 0.7
  metallic
  specular 0.80
  roughness 1/120
  reflection 0.8
};



Do reflection and specular each have their own blocks containing a 
roughness parameter?


#local ldrawChromeFin=finish {
  brilliance 6
  diffuse 0.7
  metallic
  specular {0.80 roughness 1/120}
  reflection {0.8 roughness 1/120}
};



Mike

[Mike Horvath] Re: Blurred reflections [2985 days 3 hours and 52 minutes ago]

Fri, 9 Feb 2018 12:15:43 GMT

On 2/6/2018 7:22 PM, Alain wrote:
> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>> How do I get blurred reflections working in UberPOV? I had it working 
>> a few years go, but have since forgotten how. Thanks.
>>
>>
>> Mike
> 
> You only need to add roughness into the reflection block such as :
> 
> reflection{0.9 metallic roughness 0.001}
> or
> reflection{1 fresnel roughness 0.001}
> or
> reflection{0.8 roughness 0.001}
> or
> reflection{0.1, 1 roughness 0.001}
> 
> Normally, you also want to add specular highlights with the same 
> roughness amount.

How do I set the roughness of a specular highlight?
Is there a `specular {}` block?


Mike

[Mike Horvath] Re: #version in UberPOV [2985 days 3 hours and 53 minutes ago]

Fri, 9 Feb 2018 12:14:45 GMT

On 2/9/2018 6:51 AM, clipka wrote:
> Is that with or without the `#version unofficial patch 3.71;" ??
> 
> Because if you don't specify a `#version` statement nor `Version` INI
> setting, 3.62 is the default you get.
> 

Oops, you're right. If I set the version number first it reports 3.710000.


Mike

[clipka] Re: #version in UberPOV [2985 days 4 hours and 16 minutes ago]

Fri, 9 Feb 2018 11:51:33 GMT

Am 09.02.2018 um 00:33 schrieb Mike Horvath:
> On 2/7/2018 3:57 PM, clipka wrote:
>> Am 07.02.2018 um 02:32 schrieb Mike Horvath:
>>> UberPOV has lengthy #version declarations such as the following:
>>>
>>> #version unofficial patch 3.71;
>>> #patch 0.99;
>>>
>>> How do I store the version in a variable? For instance
>>>
>>> #declare MyVersion = version;
>>>
>>> Does that still work properly?
>>
>> It should. Let me know if it doesn't.
>>
> 
> 
> I just tried
> 
> Â Â Â  #debug concat("\n\nMike's version: ",
str(version, 0, -1), "\n\n")
> 
> And it outputted
> 
> Â Â Â  Mike's version: 3.620000

Is that with or without the `#version unofficial patch 3.71;" ??

Because if you don't specify a `#version` statement nor `Version` INI
setting, 3.62 is the default you get.

[Mike Horvath] Re: #version in UberPOV [2985 days 16 hours and 34 minutes ago]

Thu, 8 Feb 2018 23:33:24 GMT

On 2/7/2018 3:57 PM, clipka wrote:
> Am 07.02.2018 um 02:32 schrieb Mike Horvath:
>> UberPOV has lengthy #version declarations such as the following:
>>
>> #version unofficial patch 3.71;
>> #patch 0.99;
>>
>> How do I store the version in a variable? For instance
>>
>> #declare MyVersion = version;
>>
>> Does that still work properly?
> 
> It should. Let me know if it doesn't.
> 


I just tried

     #debug concat("\n\nMike's version: ", str(version, 0, -1), "\n\n")

And it outputted

     Mike's version: 3.620000



Mike

[Alain] Re: Blurred reflections [2985 days 18 hours and 24 minutes ago]

Thu, 8 Feb 2018 21:44:07 GMT

Le 18-02-06 Ã  20:10, Mike Horvath a Ã©critÂ :
> On 2/6/2018 7:22 PM, Alain wrote:
>> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>>> How do I get blurred reflections working in UberPOV? I had it working 
>>> a few years go, but have since forgotten how. Thanks.
>>>
>>>
>>> Mike
>>
>> You only need to add roughness into the reflection block such as :
>>
>> reflection{0.9 metallic roughness 0.001}
>> or
>> reflection{1 fresnel roughness 0.001}
>> or
>> reflection{0.8 roughness 0.001}
>> or
>> reflection{0.1, 1 roughness 0.001}
>>
>> Normally, you also want to add specular highlights with the same 
>> roughness amount.
> 
> Thanks! What do I use in the header?
> 
> One of my old scenes uses this:
> 
> #version unofficial patch 3.71;
> #patch 0.99;
> 
> But I don't know if that's up-to-date.
> 
> 
> Mike

No longer needed.

[clipka] Re: #version in UberPOV [2986 days 19 hours and 10 minutes ago]

Wed, 7 Feb 2018 20:57:22 GMT

Am 07.02.2018 um 02:32 schrieb Mike Horvath:
> UberPOV has lengthy #version declarations such as the following:
> 
> #version unofficial patch 3.71;
> #patch 0.99;
> 
> How do I store the version in a variable? For instance
> 
> #declare MyVersion = version;
> 
> Does that still work properly?

It should. Let me know if it doesn't.

[Thomas de Groot] Re: Blurred reflections [2987 days 8 hours and 21 minutes ago]

Wed, 7 Feb 2018 07:47:09 GMT

On 7-2-2018 2:10, Mike Horvath wrote:
> On 2/6/2018 7:22 PM, Alain wrote:
>> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>>> How do I get blurred reflections working in UberPOV? I had it working 
>>> a few years go, but have since forgotten how. Thanks.
>>>
>>>
>>> Mike
>>
>> You only need to add roughness into the reflection block such as :
>>
>> reflection{0.9 metallic roughness 0.001}
>> or
>> reflection{1 fresnel roughness 0.001}
>> or
>> reflection{0.8 roughness 0.001}
>> or
>> reflection{0.1, 1 roughness 0.001}
>>
>> Normally, you also want to add specular highlights with the same 
>> roughness amount.
> 
> Thanks! What do I use in the header?
> 
> One of my old scenes uses this:
> 
> #version unofficial patch 3.71;
> #patch 0.99;
> 
> But I don't know if that's up-to-date.
> 
> 
> Mike

I have this:

#version unofficial patch 3.71;
#patch "upov-reflection-roughness" 0.9;


-- 
Thomas

[Mike Horvath] #version in UberPOV [2987 days 14 hours and 35 minutes ago]

Wed, 7 Feb 2018 01:32:31 GMT

UberPOV has lengthy #version declarations such as the following:

#version unofficial patch 3.71;
#patch 0.99;

How do I store the version in a variable? For instance

#declare MyVersion = version;

Does that still work properly?


Mike

[Mike Horvath] Re: Blurred reflections [2987 days 14 hours and 57 minutes ago]

Wed, 7 Feb 2018 01:10:41 GMT

On 2/6/2018 7:22 PM, Alain wrote:
> Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
>> How do I get blurred reflections working in UberPOV? I had it working 
>> a few years go, but have since forgotten how. Thanks.
>>
>>
>> Mike
> 
> You only need to add roughness into the reflection block such as :
> 
> reflection{0.9 metallic roughness 0.001}
> or
> reflection{1 fresnel roughness 0.001}
> or
> reflection{0.8 roughness 0.001}
> or
> reflection{0.1, 1 roughness 0.001}
> 
> Normally, you also want to add specular highlights with the same 
> roughness amount.

Thanks! What do I use in the header?

One of my old scenes uses this:

#version unofficial patch 3.71;
#patch 0.99;

But I don't know if that's up-to-date.


Mike

[Alain] Re: Blurred reflections [2987 days 15 hours and 46 minutes ago]

Wed, 7 Feb 2018 00:21:58 GMT

Le 18-02-06 Ã  19:09, Mike Horvath a Ã©critÂ :
> How do I get blurred reflections working in UberPOV? I had it working a 
> few years go, but have since forgotten how. Thanks.
> 
> 
> Mike

You only need to add roughness into the reflection block such as :

reflection{0.9 metallic roughness 0.001}
or
reflection{1 fresnel roughness 0.001}
or
reflection{0.8 roughness 0.001}
or
reflection{0.1, 1 roughness 0.001}

Normally, you also want to add specular highlights with the same 
roughness amount.

[Mike Horvath] Blurred reflections [2987 days 15 hours and 59 minutes ago]

Wed, 7 Feb 2018 00:09:04 GMT

How do I get blurred reflections working in UberPOV? I had it working a 
few years go, but have since forgotten how. Thanks.


Mike

[William F Pokorny] Re: POVRay 3.7 with depth-map unofficial patch r... [3089 days and 15 minutes ago]

Sat, 28 Oct 2017 15:53:06 GMT

On 10/28/2017 07:14 AM, clipka wrote:
> Am 28.10.2017 um 02:40 schrieb cjaramillo:
> 
...
> 
> So far, official POV-Ray does not have any such feature.
> 
> You /can/ create depth maps "out of the box" though, provided you have
> control over the scene's textures.
> 
> To do that, use `finish { diffuse 0 specular 0 phong 0 ambient 0
> emission 1 }`, and a gradient pigment rotated and translated in such a
> way that it aligns with the camera.
> 
> Make sure to render to a 16-bit image format or OpenEXR, or your depth
> map precision will be pretty low.
> 

Also doable "out of the 3.7 box," I've played with storing and 
retrieving +-64bit values in df3 files and there is a small, 
orthographic depth map example using the technique at:

http://wiki.povray.org/content/User:Wfpokorny/DensityFile/DepthMap64BitDf3RsltStoreExample

which also needs parts of the arraycoupleddf3s.inc file at:

http://wiki.povray.org/content/User:Wfpokorny/DensityFile/arraycoupleddf3s

While you do have to create a union of all objects you want as part of 
the depth map to pass to trace(), the approach doesn't require any 
special texture set up. Further because the 'depth value df3' can be 
wrapped in a function the +-64bit values can be used in later renders.

As SDL code using trace() and executed by the parser the approach is not 
fast(1) and be a little paranoid using the related include file macros. 
While I think the df3 value storage/retrieval code OK, and it worked in 
one real project of mine, it has not been much used in practice.

Bill P.

(1) With some planning and care you can run more than one povray-parser 
at a time when creating data for later use.

[clipka] Re: POVRay 3.7 with depth-map unofficial patch r... [3089 days 4 hours and 54 minutes ago]

Sat, 28 Oct 2017 11:14:02 GMT

Am 28.10.2017 um 02:40 schrieb cjaramillo:

> Hi, Ankur. Did the POV-Ray maintainers ever let you merge your depth map
> generation patch into the official code? I'm looking for a way to achieve
> generating depth maps for the rendered files as you did for the ICL-NUIM
> dataset.

So far, official POV-Ray does not have any such feature.

You /can/ create depth maps "out of the box" though, provided you have
control over the scene's textures.

To do that, use `finish { diffuse 0 specular 0 phong 0 ambient 0
emission 1 }`, and a gradient pigment rotated and translated in such a
way that it aligns with the camera.

Make sure to render to a 16-bit image format or OpenEXR, or your depth
map precision will be pretty low.

[cjaramillo] Re: POVRay 3.7 with depth-map unofficial patch r... [3089 days 15 hours and 23 minutes ago]

Sat, 28 Oct 2017 00:45:01 GMT

"handos" <han### [at] gmailcom> wrote:
> Hi Le,
>
> I've kept a README_ANKUR here at
> https://github.com/ankurhanda/povray.3.7.0.RC3.withdepthmap/blob/master/README_ANKUR
> where I explained how to use it and what output files it dumps alongside
> output.png
> There is no such enable-disable depth-map facility at the moment but I guess it
> shouldn't be too hard.
>
> I just saw that in the other forum you'd posted the answer to my question on how
> to get the camera parameters and which file to look in ;-). Thanks for that.
>
> Thanks a lot!
> Ankur.
>
>
> Le_Forgeron <jgr### [at] freefr> wrote:
> > Le 18/07/2011 00:05, handos nous fit lire :
> > > Hi Le,
> > >
> > > Thanks for having spent time on this. I understand that it's not cleaned up yet
> > > but it's just a small rudimentary version of the patch I created. I'd take your
> > > advice and clean up a bit so that it's easy for other guys to understand.
> > > My intention here was to just get some good feedback on it.
> > >
> > > Regarding the purpose, there are many applications in computer vision or
> > > graphics where one would like to have a depth-map corresponding to the image.
> > > And one might need to obtain 3D coordinates for each pixel observed in the image
> > > to aid  3D reconstruction or applications related to Augmented Reality. I had
> > > searched in the POVRay website to see if anyone had done that before with
> > > POVRay-3.7. I guess maybe working on depth-map is quite specific but just in
> > > case anyone wanted to have a depth-map along with image, it might be worth
> > > taking a look at this patch I released.
> > >
> > > I'd definitely add the original version of 3.7 into my git-hub so that it's easy
> > > to find out the patches I created.
> > >
> > > Thanks a lot!
> >
> > Nice. I would still need a basic tutorial about what happen (from an
> > external user's point of view).
> >
> > For instance, take a scene.pov; With normal 3.7RC3, the command line
> > would be "foo bar zorglub scene.pov" (well probably something more like
> > "povray -Iscene.pov -H480 -W640 +A0.01 +FN")
> > The output would be a png file, named scene.png.
> >
> > With your patched version, if I want the depth map, what is the command
> > line ? If I do not want the depth map, can I expect using the 3.7RC3
> > command line with the new binary or do I need something else ?
> > How is named the depth map file ?
> > What is its format ? How can I see it (I would like to be impressed like
> > a lambda Mac/Iphone/Ipad user: no internal techniques, just nice pictures) ?
> > Is the camera position & setting output in another file (what is its
> > name ?) or is that part of the depth map file ?
> >
> > I'm sure the people dealing with depth map on a daily basis all know
> > this stuff, but so far the poor neophytes are just left on the side of
> > the road without a clue.

Hi, Ankur. Did the POV-Ray maintainers ever let you merge your depth map
generation patch into the official code? I'm looking for a way to achieve
generating depth maps for the rendered files as you did for the ICL-NUIM
dataset.

Thanks,

Carlos

[Bald Eagle] Re: FFT internal function? [3332 days and 48 minutes ago]

Mon, 27 Feb 2017 15:20:00 GMT

http://news.povray.org/povray.binaries.images/thread/%3C42ff61ca%241%40news.povray.org%3E/

https://www.youtube.com/watch?v=oACegp4iGi0

https://github.com/ssingal05/ImageTransformer

Looks like in addition to processing images, it could be useful for generating
pigment patterns. (see @ 2:05)

[Bald Eagle] Re: FFT internal function? [3350 days 22 hours and 48 minutes ago]

Wed, 8 Feb 2017 17:20:01 GMT

How's this for old?

http://www-evasion.inrialpes.fr/people/Fabrice.Neyret/images/fluids-nuages/waves/Jonathan/articlesCG/fourier-synthesis-
of-ocean-scenes-87.pdf

:O

[Bald Eagle] Re: FFT internal function? [3353 days and 53 minutes ago]

Mon, 6 Feb 2017 15:15:01 GMT

clipka <ano### [at] anonymousorg> wrote:

> You'd need to provide a use case though, and one or more proposals for
> the scene description syntax, as I've never used FFT in the context of
> raytracing, so I have no bloody idea what it could be used for in POV-Ray ;)

I'll see what I can do.

As with many things, it's a tool that looks very useful, and something I'd like
to explore.

I had wanted to use it for "simple" signal processing - to extract the
fundamental frequencies of the data in the vibrating plate animation I did.
I'm sure that given the various transcendent, repeating, and other functions
that are used to generate various scene elements, that some clever person could
apply the Fourier transform and its inverse to do some wicked cool stuff that I
can't currently imagine or articulate.  ;)

From some of my reading, it looks like it can be used for some formas of
antialiasing, image deconvolution (sharpening), simulating types of noise, water
surfaces, etc.

http://www.bugman123.com/Fractals/index.html
(CTRL-F to search for 'fourier')
     Frequency Filtered Random Noise - Mathematica 4.2, 9/5/04

http://www.bugman123.com/Physics/index.html#Caustics
"Water Caustics - Mathematica 4.2, POV-Ray 3.1, 4/22/06
  This water-like surface was generated in Mathematica using frequency filtered
random noise, and then it was raytraced in POV-Ray and water caustics were added
using Henrik Jensen’s photon mapping technique. The smooth_triangle command was
used for phong normal interpolation of the water’s surface."

http://www.bialith.com/Research/BARclockblur.htm
http://www.deconvolve.net/index.html

[clipka] Re: FFT internal function? [3355 days 16 hours and 7 minutes ago]

Sat, 4 Feb 2017 00:01:04 GMT

Am 03.02.2017 um 18:12 schrieb Bald Eagle:
> With regard to some past experiments:
> 
> How difficult would it be to implement a fast Fourier transform as an internal
> POV-Ray / UberPOV / MegaPov function?
> 
> I'm assuming not doing this in SDL would be a whole lot faster.

It would certainly be possible, and sure as hell faster.

You'd need to provide a use case though, and one or more proposals for
the scene description syntax, as I've never used FFT in the context of
raytracing, so I have no bloody idea what it could be used for in POV-Ray ;)


> It looks like everything's all set up to 'just' plug it in - the code is
> available and free:
> 
> "Starting with version 1.3, FFTW is Free Software in the technical sense defined
> by the Free Software Foundation (see Categories of Free and Non-Free Software),
> and is distributed under the terms of the GNU General Public License."
> 
> http://www.fftw.org/

GPL for a library for which alternatives are plenty? Meh.

I'd gravitate towards an alternative with a "more free" license, maybe
Kiss FFT (BSD) or FFTReal (allegedly WTFPL).

(POV-Ray's license has been changed to AGPL solely for publicity
reasons, so that it can rightly claim to be "free software" not just in
spirit, but also in the strict sense the FSF likes to attach to the
term. To my knowledge the majority (if not all) of the dev team don't
really buy into the FSF's political agenda, and if I'm asked, the
deliberately highly contagious "copyleft" bullshit isn't free either; it
just has the sign bit flipped. But I digress...)


The GNU Scientific Library would also be something to look at, as
besides FFT it also provides other stuff we might want to use, either to
add more features or to replace some of our homegrown code with stuff
that has probably seen more trying, testing and optimizing than we could
ever hope to invest into our own implementations of the respective
functionality. (OTOH at least some of that other functionality relevant
for POV-Ray might also be available in the boost libraries by now.)

[Bald Eagle] FFT internal function? [3355 days 22 hours and 53 minutes ago]

Fri, 3 Feb 2017 17:15:00 GMT

With regard to some past experiments:

How difficult would it be to implement a fast Fourier transform as an internal
POV-Ray / UberPOV / MegaPov function?

I'm assuming not doing this in SDL would be a whole lot faster.

It looks like everything's all set up to 'just' plug it in - the code is
available and free:

"Starting with version 1.3, FFTW is Free Software in the technical sense defined
by the Free Software Foundation (see Categories of Free and Non-Free Software),
and is distributed under the terms of the GNU General Public License."

http://www.fftw.org/

[clipka] KwanPOV [3388 days 13 hours and 15 minutes ago]

Mon, 2 Jan 2017 02:52:54 GMT

Hi folks,

looks like POV-Ray 3.7 has grown a 2nd-level patch by now:

https://github.com/kwan3217/KwanPov

KwanPOV is a derivative of UberPOV. I don't understand /exactly/ what
this guy is doing, but I have a hunch that anyone dabbling with
rendering stellar bodies of the solar system might be interested in
having a closer look at it.

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3391 days 12 hours and 36 minutes ago]

Fri, 30 Dec 2016 03:31:22 GMT

omniverse <omn### [at] charternet> wrote:
> Oh yeah, if I remember this, I bought a book for Chris Cason. Looking at
> amazon.com I still see "POV-Ray Team Co-ordinator" in the Your Friends list.
> Other than that I only see a couple buys for myself, Ray Tracing Creations (two
> from 2001, 2006) and the Ray Tracing Worlds books (2006).
> 
> And there was that great key fob made possible by some people. I bought 3 so I
> could give one away and put another away to be untouched over time. Other than
> that I hadn't put any money toward POV-Ray... until now.
> 

Is there still a wish list for main Pov that anyone is aware of?

I would like to have a chat with main Pov devs too, to see what if anything
I could coordinate or work out with them to help. I may need to wait until
the UberPov effort is a little more established and proven though. Who
knows, but so far I think it has been pretty successful, and will become
more so over time.

> I will look at that, too, besides only GoFundMe for UberPOV.
> 
> Offering inclusion in the About POV-Ray pop-up by scrolling a list of donor
> names seems like a nice way to keep things going... if this kind of thing is an
> okay idea.

Yep, I am fine with whatever.

Ian

[omniverse] Re: Can I pay someone to add this from MegaPov? [3393 days 4 hours and 18 minutes ago]

Wed, 28 Dec 2016 11:50:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 08.11.2016 um 00:05 schrieb [GDS|Enropy]:
>
> > On a personal note, any bounty I pay will also have a donation to the Pov
> > Team/org as a whole if such a thing is possible. Do they have a Patreon
> > page or something? I want to make sure the whole org benefits.
>
> The POV-Ray dev team as a whole has a tradition of discouraging monetary
> donations, to protect against quarrels among all the contributors over a
> fair scheme for distributing such donations.
>
> (They did put up the occasional Amazon wishlist to get a new hard drive
> for the web server or a raytracing-related book for one of the team
> members, but that's an entirely different matter.)

Oh yeah, if I remember this, I bought a book for Chris Cason. Looking at
amazon.com I still see "POV-Ray Team Co-ordinator" in the Your Friends list.
Other than that I only see a couple buys for myself, Ray Tracing Creations (two
from 2001, 2006) and the Ray Tracing Worlds books (2006).

And there was that great key fob made possible by some people. I bought 3 so I
could give one away and put another away to be untouched over time. Other than
that I hadn't put any money toward POV-Ray... until now.

> The only crowdfunding platform the POV-Ray dev team is officially
> present on is an open source bounty platform where anyone can put up
> bounties for any issue tracked on any GitHub project, potentially
> without the project owners even knowing about this; so we officially
> claimed dibs on the POV-Ray project on their platform to assert at least
> a minimum degree of control over this mechanism. But currently we don't
> publicly advertise our presence there.

I will look at that, too, besides only GoFundMe for UberPOV.

Offering inclusion in the About POV-Ray pop-up by scrolling a list of donor
names seems like a nice way to keep things going... if this kind of thing is an
okay idea.

> As a member of the POV-Ray dev team, I stay in line with this policy.
>
> As the person behind UberPOV I tend to be less picky, and had actually
> set up means for people to funnel funds my way soon after the start of
> that project; but out of respect for my fellow contributors I'm not
> making much fuss in official POV-Ray channels about this fact (which is
> probably why nothing much has come out of it previously ;)).

#default{pigment{blue 1}}#for(I,-1,1,1)
#if(I!=0)cylinder{<I-.3,0,3>,<I-.3,1,3>,.2}#end
sphere{<I-.1,0,3>,.4}#end//bob

[clipka] Re: UberPOV is back [3430 days 22 hours and 16 minutes ago]

Sun, 20 Nov 2016 17:52:14 GMT

Am 13.09.2016 um 15:23 schrieb Mr:

> Three shaders Oren_nayar, Lomel_selliger, minnaert work well. To be nitpicky, I
> felt that the minnaert at a value of 2 which is its Blender Maximum value, the
> result looked less contrasted than Blender internal renderer. That is to say, in
> Blender, faces away from camera appeared lighter while normals facing the camera
> were darker than pov result but the overall behaviour is a much closer result
> than what we had so far !

Can you provide an image as rendered by Blender, along with a
corresponding POV-Ray scene?

Make sure to eliminate any other potential influences, such as
reflections, highlights, ambient light and whatnot.

A screenshot of the chosen Blender material settings may also be helpful.


> How would we use the second fresnel outgoing term ?

I'm not sure what you are referring to. Bear in mind that I'm not a
Blender user.

[omniverse] Re: Win10 UberPov minor locking when switching t... [3434 days 13 hours and 8 minutes ago]

Thu, 17 Nov 2016 03:00:00 GMT

[GDS|Entropy] <gdsHYPHENentropyAThotmaolDOTcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> > Am 16.11.2016 um 01:55 schrieb [GDS|Entropy]:
> >> I noticed that under Win 10 x64 that when switching to/from the UberPov
> >> window it will freeze for a second or two, and when there is a completed or
> >> working render it is a bit more pronounced.
> >>
> >> Has anyone else noticed such?
> >
> > I can't think of any reason whatsoever why that should happen with
> > UberPOV but not with official contemporary POV-Ray pre-releases. They
> > differ in the set of features, but the overall architecture is virtually
> > identical, and as of recently the pre-releases also use exactly the same
> > build environment.
>
> It is quite possible that it is some aspect of Windows 10 pro, but yes it
> is puzzling.

Win 10 64-bit here too and no pauses from program transitions, however, I've had
a couple crashes from the POV-Ray alpha versions going back a month or two.
Saved 2 sets of dump files, hundreds of megabytes. Thought I would wait to see
if it would happen a lot more or change with newer releases.

Event Viewer does show something went wrong with UberPOV in September:

Fault bucket 50, type 5
Event Name: RADAR_PRE_LEAK_64
Response: Not available
Cab Id: 0

Problem signature:
P1: uberpov64.exe
P2: 3.7.0.0
P3: 10.0.14393.2.0.0
P4:
P5:
P6:
P7:
P8:
P9:
P10:

Attached files:
\\?\C:\Users\Bob\AppData\Local\Temp\RDRFF43.tmp\empty.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERFF82.tmp.WERInternalMetadata.xml

These files may be available here:

Analysis symbol:
Rechecking for solution: 0
Report Id: 320daf4b-7a6f-11e6-9bed-dc5360a9a04b
Report Status: 0
Hashed bucket: 654db5c4b9e65eb5527a9f78fc1a0507

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
While the alpha POV-Ray very recently shows this:

Application popup: POV-Ray for Windows : Unfortunately, it appears that a memory
access violation at address 0x0000000140349AA5 has caused this unofficial
POV-Ray build to crash. This dialog will allow you to choose whether or not a
dump file (useful for diagnostics) is written.

And also going back to September, or August, I've seen an application memory
error message (possibly some other type) flash on the screen at Shutdown.
Happens too fast for me to see or read anything. Probably a dozen or more of
those to date, but I haven't tried to check what it might be in the Event Viewer
next Startup. Only looking for things now because of this message post.

[INVALID ADDRESS] Re: Win10 UberPov minor locking when switching t... [3434 days 14 hours and 13 minutes ago]

Thu, 17 Nov 2016 01:54:50 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 16.11.2016 um 01:55 schrieb [GDS|Entropy]:
>> I noticed that under Win 10 x64 that when switching to/from the UberPov
>> window it will freeze for a second or two, and when there is a completed or
>> working render it is a bit more pronounced.
>> 
>> Has anyone else noticed such?
> 
> I can't think of any reason whatsoever why that should happen with
> UberPOV but not with official contemporary POV-Ray pre-releases. They
> differ in the set of features, but the overall architecture is virtually
> identical, and as of recently the pre-releases also use exactly the same
> build environment.
> 
> 

It is quite possible that it is some aspect of Windows 10 pro, but yes it
is puzzling.

Ian

[Thomas de Groot] Re: +C not working in UberPOV [3435 days 7 hours and 48 minutes ago]

Wed, 16 Nov 2016 08:20:08 GMT

On 15-11-2016 15:21, clipka wrote:
> Am 15.11.2016 um 09:44 schrieb Thomas de Groot:
>> On 14-11-2016 22:30, omniverse wrote:
>>> And now it's okay too in the latest UberPOV with glows.
>>> Version 1.37.1-alpha.8871946.msvc14
>>
>> I can confirm this, also with stochastic antialiasing. Thanks!
>> Version 1.37.1-alpha.8871946.msvc14.win64
>
> I would consider that good news -- if it wasn't for the fact that I have
> not the faintest idea what could have broken the feature in earlier
> versions, nor what might have served to fix it now.
>

This means it might emerge again in the future. I'll keep an eye on it; 
maybe something will show.

By the way, yes, a .1 was dropped in the version number ;-)

-- 
Thomas

[clipka] Re: Win10 UberPov minor locking when switching t... [3435 days 12 hours and 47 minutes ago]

Wed, 16 Nov 2016 03:20:19 GMT

Am 16.11.2016 um 01:55 schrieb [GDS|Entropy]:
> I noticed that under Win 10 x64 that when switching to/from the UberPov
> window it will freeze for a second or two, and when there is a completed or
> working render it is a bit more pronounced.
> 
> Has anyone else noticed such?

I can't think of any reason whatsoever why that should happen with
UberPOV but not with official contemporary POV-Ray pre-releases. They
differ in the set of features, but the overall architecture is virtually
identical, and as of recently the pre-releases also use exactly the same
build environment.

[INVALID ADDRESS] Win10 UberPov minor locking when switching to/from [3435 days 15 hours and 12 minutes ago]

Wed, 16 Nov 2016 00:55:51 GMT

I noticed that under Win 10 x64 that when switching to/from the UberPov
window it will freeze for a second or two, and when there is a completed or
working render it is a bit more pronounced.

Has anyone else noticed such?

Ian

[INVALID ADDRESS] Re: +C not working in UberPOV [3435 days 19 hours and 10 minutes ago]

Tue, 15 Nov 2016 20:57:18 GMT

clipka <ano### [at] anonymousorg> wrote:
> I would consider that good news -- if it wasn't for the fact that I have
> not the faintest idea what could have broken the feature in earlier
> versions, nor what might have served to fix it now.
> 

I hate it when that happens.
Usually an indicator of some hidden dependency or side effect of course,
and finding it is always loads of fun.

Ian

[INVALID ADDRESS] Re: MegaPOV glows in UberPOV [3435 days 19 hours and 11 minutes ago]

Tue, 15 Nov 2016 20:57:17 GMT

clipka <ano### [at] anonymousorg> wrote:
>> It may be interesting at a later date to make them an actual volumetric
>> effect if they do not work that way currently.
> 
> Define "volumetric effect".
> 
> If you mean "an effect depending on properties of a 3D region of space,
> as opposed to properties of a surface", then glow already is a
> volumetric effect.
> 
> If you mean "an effect computed by numeric integration along a ray, as
> opposed to symbolic integration", then no, glow does not match that
> definition. But I don't think it makes much sense to redesign the glow
> feature in such a manner: Like fog it is a lightweight feature, thanks
> to the use of symbolic integration, which comes at the cost of
> imperfections; changing it to use numeric integration could eliminate
> those imperfections, but would also turn it into heavyweight feature. If
> you want to realistically model halos caused by some scattering medium,
> use... (drumroll)... scattering media.
> 

That makes complete sense in every way, and since I already implemented a
scattering media based glow, I can use those for ones close to the camera
and the normal ones otherwise.

I wasn't able to get the falloff of density and intensity to match real
glows quite correctly, because I do not know the function operating behind
it (and because of how media scales and/or my ignorance I had to use nested
shells), though if I did have the algorithm I could probably improve that
macro so we would have a "high quality" setting/macro available, which
might make a nice standard include.

I think I posted the source for it on the NG somewhere.

Ian

[omniverse] Re: +C not working in UberPOV [3435 days 22 hours and 43 minutes ago]

Tue, 15 Nov 2016 17:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
>
> Are you two guys sure about that version number? Or could it have been
> 1.37.1.1-whatever? ;)

Wups. Yep, 1.37.1.1-

[clipka] Re: +C not working in UberPOV [3436 days 1 hour and 47 minutes ago]

Tue, 15 Nov 2016 14:21:15 GMT

Am 15.11.2016 um 09:44 schrieb Thomas de Groot:
> On 14-11-2016 22:30, omniverse wrote:
>> And now it's okay too in the latest UberPOV with glows.
>> Version 1.37.1-alpha.8871946.msvc14
> 
> I can confirm this, also with stochastic antialiasing. Thanks!
> Version 1.37.1-alpha.8871946.msvc14.win64

I would consider that good news -- if it wasn't for the fact that I have
not the faintest idea what could have broken the feature in earlier
versions, nor what might have served to fix it now.

[clipka] Re: +C not working in UberPOV [3436 days 2 hours and 20 minutes ago]

Tue, 15 Nov 2016 13:47:39 GMT

Am 15.11.2016 um 09:44 schrieb Thomas de Groot:
> On 14-11-2016 22:30, omniverse wrote:
>> And now it's okay too in the latest UberPOV with glows.
>> Version 1.37.1-alpha.8871946.msvc14
> 
> I can confirm this, also with stochastic antialiasing. Thanks!
> Version 1.37.1-alpha.8871946.msvc14.win64

Are you two guys sure about that version number? Or could it have been
1.37.1.1-whatever? ;)

[clipka] Re: MegaPOV glows in UberPOV [3436 days 2 hours and 25 minutes ago]

Tue, 15 Nov 2016 13:43:14 GMT

Am 15.11.2016 um 02:33 schrieb [GDS|Entropy]:

>> It may come as a surprise to you, but the glow feature is entirely
>> independent of media, so there's no reason to tie modifications of one
>> to the other.
> 
> It is surprising, both because Glows look the way the do, and because I had
> thought there was perhaps a greater tie between the two functions due to
> your previous mention that resolving the glow bug was related to scattering
> media in some way.

What I meant was that the glow artifacts I was thinking of were inherent
to the simplicity of the glow algorithm, and that repairing them would
mean redesigning the feature to use a much more complex algorithm very
similar to that of scattering media.

> How do glows work? Is it like the fog keyword? They tend to have a fog sort
> of effect on their own without media or fog.

The feature with the most similarities is probably ground fog.

> It may be interesting at a later date to make them an actual volumetric
> effect if they do not work that way currently.

Define "volumetric effect".

If you mean "an effect depending on properties of a 3D region of space,
as opposed to properties of a surface", then glow already is a
volumetric effect.

If you mean "an effect computed by numeric integration along a ray, as
opposed to symbolic integration", then no, glow does not match that
definition. But I don't think it makes much sense to redesign the glow
feature in such a manner: Like fog it is a lightweight feature, thanks
to the use of symbolic integration, which comes at the cost of
imperfections; changing it to use numeric integration could eliminate
those imperfections, but would also turn it into heavyweight feature. If
you want to realistically model halos caused by some scattering medium,
use... (drumroll)... scattering media.

[Thomas de Groot] Re: +C not working in UberPOV [3436 days 7 hours and 23 minutes ago]

Tue, 15 Nov 2016 08:44:22 GMT

On 14-11-2016 22:30, omniverse wrote:
> And now it's okay too in the latest UberPOV with glows.
> Version 1.37.1-alpha.8871946.msvc14
>
>

I can confirm this, also with stochastic antialiasing. Thanks!
Version 1.37.1-alpha.8871946.msvc14.win64

-- 
Thomas

[Thomas de Groot] Re: +C not working in UberPOV [3436 days 8 hours and 16 minutes ago]

Tue, 15 Nov 2016 07:51:27 GMT

On 14-11-2016 15:17, clipka wrote:
> Am 14.11.2016 um 13:50 schrieb Thomas de Groot:
>> Somehow +C or +c is not working in UberPOV
>> 1.37.1.1-alpha.8756754.msvc14. Restarting the interrupted render
>> restarts the image at the first pixel.
>>
>> +C works fine in versions 3.7 and 3.71.
>
> Can you be more specific about that "3.71" you're talking about?
>

Sorry for that. Is 3.7.1-alpha.8141620.unofficial.msvc10.

The problem in UberPOV was unrelated to stochastic aa or any other 
particularity for UberPOV.

-- 
Thomas

[INVALID ADDRESS] Re: MegaPOV glows in UberPOV [3436 days 14 hours and 35 minutes ago]

Tue, 15 Nov 2016 01:33:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 15.11.2016 um 01:13 schrieb [GDS|Enropy]:
> 
> [Whoops -- what happened to the "t" in your user name?]

Good catch; that has likely been missing since I first setup the account in
NewsTap, so, years! Haha!

> Yes, for now I consider it the mission to be establishing a baseline for
> the feature, matching MegaPOV as closely as possible (except for the
> presumed scaling bug). Non-trivial bug fixes may follow sooner or later,
> but they're not priority.
> 
> Which is why I'd love to hear whether the issues reported by omniverse
> are also seen with MegaPOV.

I have a scene or two planned that should put it through its paces. :)

> It may come as a surprise to you, but the glow feature is entirely
> independent of media, so there's no reason to tie modifications of one
> to the other.

It is surprising, both because Glows look the way the do, and because I had
thought there was perhaps a greater tie between the two functions due to
your previous mention that resolving the glow bug was related to scattering
media in some way.

How do glows work? Is it like the fog keyword? They tend to have a fog sort
of effect on their own without media or fog.

It may be interesting at a later date to make them an actual volumetric
effect if they do not work that way currently.

Ian

[clipka] Re: MegaPOV glows in UberPOV [3436 days 15 hours and 15 minutes ago]

Tue, 15 Nov 2016 00:52:21 GMT

Am 15.11.2016 um 01:13 schrieb [GDS|Enropy]:

[Whoops -- what happened to the "t" in your user name?]

> There are some known legacy bugs with Glows, such as them showing through
> solid objects, and perhaps if it proves vexing enough we can address some
> of those at a later time.

Yes, for now I consider it the mission to be establishing a baseline for
the feature, matching MegaPOV as closely as possible (except for the
presumed scaling bug). Non-trivial bug fixes may follow sooner or later,
but they're not priority.

Which is why I'd love to hear whether the issues reported by omniverse
are also seen with MegaPOV.

> However some of them are impractical to tackle at this time in my opinion,
> like the issue I mentioned above.
> 
> Such things might be best handled at a later time when there is a cohesive
> plan involving scattering media/media in general, but I am unaware of any
> planned additions/extensions or modifications to the media implementation.

It may come as a surprise to you, but the glow feature is entirely
independent of media, so there's no reason to tie modifications of one
to the other.

[INVALID ADDRESS] Re: MegaPOV glows in UberPOV [3436 days 15 hours and 54 minutes ago]

Tue, 15 Nov 2016 00:13:32 GMT

clipka <ano### [at] anonymousorg> wrote:
> There is no difference in render output between a stand-alone glow and a
> light source glow -- the difference you're seeing is caused by the
> differences in the glow parameters.
> 
> As for the other parameters (camera and/or glow being located inside an
> object, with hollow on or off) I think there's indeed something strange
> going on, but we'll need a comparison with MegaPOV output to decide what
> to do about it.

There are some known legacy bugs with Glows, such as them showing through
solid objects, and perhaps if it proves vexing enough we can address some
of those at a later time.

However some of them are impractical to tackle at this time in my opinion,
like the issue I mentioned above.

Such things might be best handled at a later time when there is a cohesive
plan involving scattering media/media in general, but I am unaware of any
planned additions/extensions or modifications to the media implementation.

I would of course be happy to sponsor such efforts once I have completed
the transfers for the Glow feature, but I leave both the creation and
prioritization of any such list to the developers, and will simply
reinforce their efforts as much as I can in any way they feel would be
positive.

Should a short list of their big to-do items be released, perhaps with a
funding threshold for each item based on what it would take to make the
effort worth it, I shall happily back it. GoFundMe might be an idea, I
don't know if that platform allows itemized lists or not though.

It would be awful, unfair, and would spell the doom of this idea for them
to engage a complex beast of a feature only to have the funding come down
to only myself (though I may be but a trickle, I will not wane); thus
having a threshold before work begins may be a prudent course.

I do not wish to get in their way, but instead to smooth it and enable more
dedicated work on bigger features than might otherwise occur in a given
time, and invite everyone to join me in support of their grand effort.

These folks have done a wonderful job over the years and I sure as heck am
not about to attempt to meddle with that, but instead only to enable it
further. The control is theirs, and I respect them all.

Ian

[clipka] Re: MegaPOV glows in UberPOV [3436 days 17 hours and 24 minutes ago]

Mon, 14 Nov 2016 22:43:44 GMT

Am 14.11.2016 um 23:05 schrieb omniverse:
> I don't have MegaPOV to compare with and I can't remember anything about glows,
> but I'm wondering if this might be incorrect behavior.
> 
> Hollow doesn't seem to matter if the glow is used in a light, and maybe that's
> instended, however a standalone glow will only disappear if viewed from within a
> non-hollow sphere (I have not checked other objects). In other words, if viewed
> from outside a non-hollow sphere the glow still shows as though it fills the
> sphere.

There is no difference in render output between a stand-alone glow and a
light source glow -- the difference you're seeing is caused by the
differences in the glow parameters.

As for the other parameters (camera and/or glow being located inside an
object, with hollow on or off) I think there's indeed something strange
going on, but we'll need a comparison with MegaPOV output to decide what
to do about it.

[omniverse] Re: MegaPOV glows in UberPOV [3436 days 17 hours and 58 minutes ago]

Mon, 14 Nov 2016 22:10:01 GMT

I don't have MegaPOV to compare with and I can't remember anything about glows,
but I'm wondering if this might be incorrect behavior.

Hollow doesn't seem to matter if the glow is used in a light, and maybe that's
instended, however a standalone glow will only disappear if viewed from within a
non-hollow sphere (I have not checked other objects). In other words, if viewed
from outside a non-hollow sphere the glow still shows as though it fills the
sphere.

And not only that, another glow outside the sphere will disappear when it's on
the other side of camera if that semi-transparent sphere is non-hollow.

Scene file to test with, because I know that probably sounds confusing.

/* test glows using hollow and non-hollow sphere (Envelope) */

#version 3.7;

global_settings
 {
  assumed_gamma 1
 }

#local Envelope=no; // enclose non-hollow sphere around camera
#local Hollow=yes; // make hollow?

camera
{
 location <1,3,33>
 look_at <0,0,0>
}

light_source
{
 z*3, <1,1,0>
glow {
  type 0//0 | 1 | 2 | 3
  location <0,11,-11>
  size 0.5
  radius 4
  fade_power 2
 // color <1,0,0>
  //rotate translate
}
translate <-10,-10,-10>
 rotate <15,-45,0>
}

glow {
  type 3//0 | 1 | 2 | 3
  location 0
  size 11
  radius 33
  fade_power 2
  color <1,0,1>
  //rotate translate
}

#if (Envelope=yes)
sphere{0,36 hollow off pigment {rgb <1,0,0> transmit 0.5}}
#elseif (Hollow)
sphere{0,33 hollow on pigment {rgb <1,0,0> transmit 0.5}}
#else
sphere{0,33 hollow off pigment {rgb <1,0,0> transmit 0.5}}
#end

[omniverse] Re: +C not working in UberPOV [3436 days 18 hours and 33 minutes ago]

Mon, 14 Nov 2016 21:35:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 14.11.2016 um 13:50 schrieb Thomas de Groot:
> > Somehow +C or +c is not working in UberPOV
> > 1.37.1.1-alpha.8756754.msvc14. Restarting the interrupted render
> > restarts the image at the first pixel.
> >
> > +C works fine in versions 3.7 and 3.71.
>
> Can you be more specific about that "3.71" you're talking about?

Can't say for Thomas, but for me it was the version:
3.7.1-alpha.8820458+av228.msvc14.win64
Continue works okay in that.

And now it's okay too in the latest UberPOV with glows.
Version 1.37.1-alpha.8871946.msvc14

[LanuHum] Re: MegaPOV glows in UberPOV [3436 days 22 hours and 13 minutes ago]

Mon, 14 Nov 2016 17:55:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 14.11.2016 um 17:21 schrieb LanuHum:
>
> > I Megapov unknown. Can I help you? :)
>
> Sure. Look up MegaPOV's glow feature at
> http://megapov.inetart.net/manual-1.2.1/effects.html and toy around with
> its implementation in UberPOV.
>
> Adding support for the feature to Blender would also be appreciated ;)

o.k.  :)))

[clipka] Re: UberPOV wit MegaPOV glows for mac available [3436 days 22 hours and 14 minutes ago]

Mon, 14 Nov 2016 17:54:05 GMT

Am 14.11.2016 um 18:46 schrieb E-mailyvo s gmx.net:
> UberPOV with MegaPOV glows is now available for Macintosh:

You're quick :)

[Yvo Smellenbergh] Re: UberPOV wit MegaPOV glows for mac available [3436 days 22 hours and 19 minutes ago]

Mon, 14 Nov 2016 17:48:24 GMT

On 2016-11-14 17:46:23 +0000, Yvo Smellenbergh said:
FYI:
only direct links, not listed on the website until out of beta :-)

Yvo


> UberPOV with MegaPOV glows is now available for Macintosh:
> 
> Executable OSX 10.7.4 and later, 64bit only
>
http://megapov.inetart.net/povrayunofficial_mac/uberpov_downloads/UberPOV-1.37.1.1-alpha.8871946-Glow.zip

> 
> 
> Source:
>
http://megapov.inetart.net/povrayunofficial_mac/uberpov_downloads/UberPOV-1.37.1.1-alpha.8871946-Glow-source.zip

> 
> 
> Discusion:
>
http://news.povray.org/povray.unofficial.patches/thread/%3C5829de00%241%40news.povray.org%3E/

> 
> 
> Yvo
> 
> Simple sample scene:
> 
> // Persistence Of Vision Ray Tracer Scene Description File
> // -------------------------------------------------------
> // File: @(#)glowlits.pov
> // Description: Here the glow effects are coupled with light sources.
> // Features demonstrated: glow
> // Creation Date: $ 27 Sep 2000, 16:08:45 $
> // Last modified: $ 14 Jun 2004, 22:36:41 $
> // Author: Chris Huff
> //
> // -w320 -h240 +a0.3
> 
> #version unofficial patch 3.7;
> 
> global_settings {
> 	assumed_gamma 1.0
> }
> 
> camera {
> 	location <-5, 6,-18>
> 	up y*image_height right x*image_width
> 	look_at < 0, 1.5, 0>
> 	angle 45
> }
> 
> //Types:
> #local Float = 0;
> #local Vector = < 0, 0, 0>;
> #local Color = color rgb < 0, 0, 0>;
> 
> #macro SRand(RS) (rand(RS)*2 - 1) #end
> #macro RRand(RS, Min, Max) (rand(RS)*(Max-Min) + Min) #end
> #macro Clamp(V, Min, Max) (min(Max, max(Min, V))) #end
> #macro Range(V, Rmn, Rmx) (V*(Rmx-Rmn) + Rmn) #end
> #macro RClamp(V, Rmn, Rmx, Min, Max) (Clamp(Range(V, Rmn, Rmx), Min, Max)) #end
> 
> #local RsA = seed(574647);
> 
> #local J = Float;
> #local J = 0;
> #while(J<52)
> 	light_source {
> 		< SRand(RsA)*8, rand(RsA)*4, SRand(RsA)*8>
> 		color rgb 0.045*< rand(RsA), rand(RsA), rand(RsA)>
> 		glow { size rand(RsA)*0.65 type int(rand(RsA))}
> 		fade_distance 4 fade_power 2
> 	}
> 	 #declare  J = J + 1;
> #end
> 
> box {
> 	<-15, 0,-10>, < 15, 0, 10>
> 	pigment {checker color rgb 0.05, color rgb 1}
> 	finish {
> 		reflection {0.5, 0.75 metallic }
> 		diffuse 0.25 ambient 0
> 	}
> }
> 
> sphere {
> 	< 0, 2, 0>, 2
> 	pigment {rgb 1}
> 	finish {
> 		reflection { 0.5, 0.85 metallic }
> 		diffuse 0.15 ambient 0
> 	}
> }
> 
> 
> 
>
-------------------------------------------------------------------------------------------

> 
> POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
> UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
> MegaPOV: http://megapov.inetart.net
> E-mail: yvo(DOT)s(AT)gmx.net


--
Yvo

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


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[Yvo Smellenbergh] UberPOV wit MegaPOV glows for mac available [3436 days 22 hours and 21 minutes ago]

Mon, 14 Nov 2016 17:46:24 GMT

UberPOV with MegaPOV glows is now available for Macintosh:

Executable OSX 10.7.4 and later, 64bit only
http://megapov.inetart.net/povrayunofficial_mac/uberpov_downloads/UberPOV-1.37.1.1-alpha.8871946-Glow.zip



Source:
http://megapov.inetart.net/povrayunofficial_mac/uberpov_downloads/UberPOV-1.37.1.1-alpha.8871946-Glow-source.zip



Discusion:
http://news.povray.org/povray.unofficial.patches/thread/%3C5829de00%241%40news.povray.org%3E/



Yvo

Simple sample scene:

// Persistence Of Vision Ray Tracer Scene Description File
// -------------------------------------------------------
// File: @(#)glowlits.pov
// Description: Here the glow effects are coupled with light sources.
// Features demonstrated: glow
// Creation Date: $ 27 Sep 2000, 16:08:45 $
// Last modified: $ 14 Jun 2004, 22:36:41 $
// Author: Chris Huff
//
// -w320 -h240 +a0.3

#version unofficial patch 3.7;

global_settings {
	assumed_gamma 1.0
}

camera {
	location <-5, 6,-18>
	up y*image_height right x*image_width
	look_at < 0, 1.5, 0>
	angle 45
}

//Types:
#local Float = 0;
#local Vector = < 0, 0, 0>;
#local Color = color rgb < 0, 0, 0>;

#macro SRand(RS) (rand(RS)*2 - 1) #end
#macro RRand(RS, Min, Max) (rand(RS)*(Max-Min) + Min) #end
#macro Clamp(V, Min, Max) (min(Max, max(Min, V))) #end
#macro Range(V, Rmn, Rmx) (V*(Rmx-Rmn) + Rmn) #end
#macro RClamp(V, Rmn, Rmx, Min, Max) (Clamp(Range(V, Rmn, Rmx), Min, Max)) #end

#local RsA = seed(574647);

#local J = Float;
#local J = 0;
#while(J<52)
	light_source {
		< SRand(RsA)*8, rand(RsA)*4, SRand(RsA)*8>
		color rgb 0.045*< rand(RsA), rand(RsA), rand(RsA)>
		glow { size rand(RsA)*0.65 type int(rand(RsA))}
		fade_distance 4 fade_power 2
	}
	 #declare  J = J + 1;
#end

box {
	<-15, 0,-10>, < 15, 0, 10>
	pigment {checker color rgb 0.05, color rgb 1}
	finish {
		reflection {0.5, 0.75 metallic }
		diffuse 0.25 ambient 0
	}
}

sphere {
	< 0, 2, 0>, 2
	pigment {rgb 1}
	finish {
		reflection { 0.5, 0.85 metallic }
		diffuse 0.15 ambient 0
	}
}



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


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[clipka] Re: MegaPOV glows in UberPOV [3436 days 23 hours and 16 minutes ago]

Mon, 14 Nov 2016 16:51:49 GMT

Am 14.11.2016 um 17:21 schrieb LanuHum:

> I Megapov unknown. Can I help you? :)

Sure. Look up MegaPOV's glow feature at
http://megapov.inetart.net/manual-1.2.1/effects.html and toy around with
its implementation in UberPOV.

Adding support for the feature to Blender would also be appreciated ;)

[LanuHum] Re: MegaPOV glows in UberPOV [3436 days 23 hours and 43 minutes ago]

Mon, 14 Nov 2016 16:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Hi folks,
>
> UberPOV now supports MegaPOV glows!
>
> The implementation still resides in a separate branch (feature/glow),
> but it is definitely going to be integrated into the main development
> branch as soon as I am confident that it works as intended.
>
> You can find Windows binaries and the source code on GitHub:
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8871946
>
> Please give it a thorough test drive, let me know if you find any
> errors, and most of all enjoy! :)
>
> During testing, please pay special attention to the scaling of light
> sources with glows; Judging from the code I think MegaPOV 1.2.1 must
> have had a bug there, which I fixed in the UberPOV implementation.
>
>
> Kudos at this point to Chris Huff for providing the original
> implementation as included in MegaPOV, as well as GDS|Entropy for what
> I'd like to call valuable support.
>
>
> Christoph

I Megapov unknown. Can I help you? :)

[clipka] MegaPOV glows in UberPOV [3437 days and 14 minutes ago]

Mon, 14 Nov 2016 15:53:36 GMT

Hi folks,

UberPOV now supports MegaPOV glows!

The implementation still resides in a separate branch (feature/glow),
but it is definitely going to be integrated into the main development
branch as soon as I am confident that it works as intended.

You can find Windows binaries and the source code on GitHub:
https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8871946

Please give it a thorough test drive, let me know if you find any
errors, and most of all enjoy! :)

During testing, please pay special attention to the scaling of light
sources with glows; Judging from the code I think MegaPOV 1.2.1 must
have had a bug there, which I fixed in the UberPOV implementation.


Kudos at this point to Chris Huff for providing the original
implementation as included in MegaPOV, as well as GDS|Entropy for what
I'd like to call valuable support.


Christoph

[clipka] Re: +C not working in UberPOV [3437 days 1 hour and 50 minutes ago]

Mon, 14 Nov 2016 14:17:27 GMT

Am 14.11.2016 um 13:50 schrieb Thomas de Groot:
> Somehow +C or +c is not working in UberPOV
> 1.37.1.1-alpha.8756754.msvc14. Restarting the interrupted render
> restarts the image at the first pixel.
> 
> +C works fine in versions 3.7 and 3.71.

Can you be more specific about that "3.71" you're talking about?

[omniverse] Re: +C not working in UberPOV [3437 days 2 hours and 18 minutes ago]

Mon, 14 Nov 2016 13:50:00 GMT

Thomas de Groot <tho### [at] degrootorg> wrote:
> Somehow +C or +c is not working in UberPOV
> 1.37.1.1-alpha.8756754.msvc14. Restarting the interrupted render
> restarts the image at the first pixel.
>
> +C works fine in versions 3.7 and 3.71.

Confirm same with 1.37.1.1-alpha.8767927.msvc14

[clipka] Re: +C not working in UberPOV [3437 days 2 hours and 18 minutes ago]

Mon, 14 Nov 2016 13:49:47 GMT

Am 14.11.2016 um 13:50 schrieb Thomas de Groot:
> Somehow +C or +c is not working in UberPOV
> 1.37.1.1-alpha.8756754.msvc14. Restarting the interrupted render
> restarts the image at the first pixel.

Is this a general problem, or just when using certain UberPOV-specific
features (such as anti-aliasing mode 3)?

[Thomas de Groot] +C not working in UberPOV [3437 days 3 hours and 17 minutes ago]

Mon, 14 Nov 2016 12:50:43 GMT

Somehow +C or +c is not working in UberPOV 
1.37.1.1-alpha.8756754.msvc14. Restarting the interrupted render 
restarts the image at the first pixel.

+C works fine in versions 3.7 and 3.71.

-- 
Thomas

[Thomas de Groot] Re: Can I pay someone to add this from MegaPov? [3441 days 8 hours ago]

Thu, 10 Nov 2016 08:07:58 GMT

On 8-11-2016 20:22, [GDS|Enropy] wrote:
> Honestly to the best of my knowledge the only true free markets we have
> anymore are very small scale and highly localized, representing individual
> transactions between private individuals. IMO there are no current national
> level examples of free market any more; it is all globalist-corporatist
> combines...but that is neither here nor there lol!

Sorry, but you need to wake up. I could cite numerous examples from 
large (steel; transportation) to small (garlic) where a dramatic drop in 
quality can be monitored in my country over the past 10 years. Not to 
speak about the rise of corruption. All mostly the result of increasing 
free-market economy regulations by the government.

However, we drift off.... :-)

>
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> On 8-11-2016 0:05, [GDS|Enropy] wrote:
>>> As far as highest bid getting the work, well that is free market economy
>>> for you. ;-) if someone is willing to pay then they obviously care enough
>>> about that feature to trade their money for it, which is a completely valid
>>> exchange.
>>
>> I don't think I need to explain what I think of free market economy... ;-)
>>
>
>
>


-- 
Thomas

[Mr] Re: UberPOV is back [3442 days 7 hours and 38 minutes ago]

Wed, 9 Nov 2016 08:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 13.09.2016 um 15:23 schrieb Mr:
>
> > Three shaders Oren_nayar, Lomel_selliger, minnaert work well. To be nitpicky, I
> > felt that the minnaert at a value of 2 which is its Blender Maximum value, the
> > result looked less contrasted than Blender internal renderer. That is to say, in
> > Blender, faces away from camera appeared lighter while normals facing the camera
> > were darker than pov result but the overall behaviour is a much closer result
> > than what we had so far !
> >
> > How would we use the second fresnel outgoing term ?
>
> Just so you know: This post of yours hasn't been forgotten; I've still
> have to find the time to get back to it though.

Thanks a lot, it's a good addition and I do hope that all this will make it into
official pov as well

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3442 days 20 hours and 35 minutes ago]

Tue, 8 Nov 2016 19:32:58 GMT

I can certainly understand and do see the intent and respect the point
behind their/your decision.

I just wish there was more I could *do*. I will never have the time to
become a contributor, unfortunately, as between work, family, and my own
projects with multiscale models of reaction-diffusion, cellular automata
and other items (a hobby which only gets an hour or two a week) my time is
just gone.

I guess the best vector for inroads will still be through UberPov, so I'm
going to back that.

Think about a list of things I could help sponsor and once we take care of
business in December we can look at starting on that list.

You are in a better position than I, to know what would do the most good.

Ian

clipka <ano### [at] anonymousorg> wrote:
> Am 08.11.2016 um 00:05 schrieb [GDS|Enropy]:
> 
>> On a personal note, any bounty I pay will also have a donation to the Pov
>> Team/org as a whole if such a thing is possible. Do they have a Patreon
>> page or something? I want to make sure the whole org benefits.
> 
> The POV-Ray dev team as a whole has a tradition of discouraging monetary
> donations, to protect against quarrels among all the contributors over a
> fair scheme for distributing such donations.
> 
> (They did put up the occasional Amazon wishlist to get a new hard drive
> for the web server or a raytracing-related book for one of the team
> members, but that's an entirely different matter.)
> 
> 
> The only crowdfunding platform the POV-Ray dev team is officially
> present on is an open source bounty platform where anyone can put up
> bounties for any issue tracked on any GitHub project, potentially
> without the project owners even knowing about this; so we officially
> claimed dibs on the POV-Ray project on their platform to assert at least
> a minimum degree of control over this mechanism. But currently we don't
> publicly advertise our presence there.
> 
> 
> As a member of the POV-Ray dev team, I stay in line with this policy.
> 
> As the person behind UberPOV I tend to be less picky, and had actually
> set up means for people to funnel funds my way soon after the start of
> that project; but out of respect for my fellow contributors I'm not
> making much fuss in official POV-Ray channels about this fact (which is
> probably why nothing much has come out of it previously ;)).
> 
>

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3442 days 20 hours and 46 minutes ago]

Tue, 8 Nov 2016 19:22:04 GMT

Honestly to the best of my knowledge the only true free markets we have
anymore are very small scale and highly localized, representing individual
transactions between private individuals. IMO there are no current national
level examples of free market any more; it is all globalist-corporatist
combines...but that is neither here nor there lol!

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 8-11-2016 0:05, [GDS|Enropy] wrote:
>> As far as highest bid getting the work, well that is free market economy
>> for you. ;-) if someone is willing to pay then they obviously care enough
>> about that feature to trade their money for it, which is a completely valid
>> exchange.
> 
> I don't think I need to explain what I think of free market economy... ;-)
>

[clipka] Re: Can I pay someone to add this from MegaPov? [3443 days 5 hours and 59 minutes ago]

Tue, 8 Nov 2016 10:08:21 GMT

Am 08.11.2016 um 00:05 schrieb [GDS|Enropy]:

> On a personal note, any bounty I pay will also have a donation to the Pov
> Team/org as a whole if such a thing is possible. Do they have a Patreon
> page or something? I want to make sure the whole org benefits.

The POV-Ray dev team as a whole has a tradition of discouraging monetary
donations, to protect against quarrels among all the contributors over a
fair scheme for distributing such donations.

(They did put up the occasional Amazon wishlist to get a new hard drive
for the web server or a raytracing-related book for one of the team
members, but that's an entirely different matter.)


The only crowdfunding platform the POV-Ray dev team is officially
present on is an open source bounty platform where anyone can put up
bounties for any issue tracked on any GitHub project, potentially
without the project owners even knowing about this; so we officially
claimed dibs on the POV-Ray project on their platform to assert at least
a minimum degree of control over this mechanism. But currently we don't
publicly advertise our presence there.


As a member of the POV-Ray dev team, I stay in line with this policy.

As the person behind UberPOV I tend to be less picky, and had actually
set up means for people to funnel funds my way soon after the start of
that project; but out of respect for my fellow contributors I'm not
making much fuss in official POV-Ray channels about this fact (which is
probably why nothing much has come out of it previously ;)).

[clipka] Re: UberPOV is back [3443 days 7 hours and 27 minutes ago]

Tue, 8 Nov 2016 08:40:33 GMT

Am 13.09.2016 um 15:23 schrieb Mr:

> Three shaders Oren_nayar, Lomel_selliger, minnaert work well. To be nitpicky, I
> felt that the minnaert at a value of 2 which is its Blender Maximum value, the
> result looked less contrasted than Blender internal renderer. That is to say, in
> Blender, faces away from camera appeared lighter while normals facing the camera
> were darker than pov result but the overall behaviour is a much closer result
> than what we had so far !
> 
> How would we use the second fresnel outgoing term ?

Just so you know: This post of yours hasn't been forgotten; I've still
have to find the time to get back to it though.

[Thomas de Groot] Re: Can I pay someone to add this from MegaPov? [3443 days 7 hours and 43 minutes ago]

Tue, 8 Nov 2016 08:24:26 GMT

On 8-11-2016 0:33, [GDS|Enropy] wrote:
> My apologies man, I didn't know the posts were going here as my reader (iOS
> NewsTap) was not subbed to this group, I intended no disrespect. :)

Ah! so my initiative was not useless after all! My instinct proved me 
true. :-)

>
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Why is our community in trouble? It seems to me that over the last
>> couple of years at least there has been quite a lot of activity by our
>> respected POV-Ray developers.
>>
>
> Beyond the google trends result that the searches for pov have decreased
> 100x since 2004, I am considering the volume of posts, new/extant pages
> about pov or with pov content, places I see Pov mentioned around the web,
> etc compared to the same from around lets say, 1994-1998 or so.
>
> There were once numerous Pov webrings, many new folks coming through all
> the time, loads of IRC activity, all kinds of unofficial patches,
> specifically pov supporting shareware...substantially all of that
> has...ebbed. :'-(
>
> Us old guys and the badasses writing the code are all that is left it
> seems. I have seen a lot go away over the last twenty something years.

Yes, and yes, and yes indeed. I find it truly sad and cannot explain all 
of it (see below for some thoughts about that). Partly it seems, people 
got just bored with POV-Ray when they had played extensively with it, 
and then just discarded the old toy for the next new shiny excitement of 
the day.

Talking of the IRTC, you know about the TC-RTC which replaced it? 
http://www.tc-rtc.co.uk/index/index.html and the discussions/news are 
also on irtc.general news group here. We certainly do not have a very 
large audience and participation but we struggle on...

>
>>
>> Maybe...
>>
>
> Anything that we can do which would drive more people to use Pov I am down
> for, and I think that will be achieved through having certain (I don't have
> a list) features combined with the quality of render, speed and one of the
> most important things....having plugins for commonly used modeling packages
> that interop with PovRay.
>
> Getting textures from app A to render in pov...thats one hellova sticky
> bit. Interop is a big, difficult thing, but ultimately you see that the
> fastest growing renderers grow precisely because of the properties I listed
> above.
>
> If I am missing anything let me know.
>
>>
>> There has been a drop of activity, mainly on the users side, with the
>> old guard turning away to other activities for instance but maybe also
>> because of age. Maybe that was due to the state-of-the-art of POV-Ray,
>> maybe not; I seem to remember some discussion about this in the past.
>> However, there has also been some new additions to the community, and I
>> think that - coming out of the "experimental" (?) stage - images have
>> become more complex/involved and/or needing more time and thought to be
>> composed. It certainly has evolved for me like that. And talking of age,
>> my own POV-Ray production is slowly dwindling over the years and that is
>> largely due to those same years accumulating on my shoulders. At
>> seventy, I am not as productive any more as I was twenty years ago.
>>
>
> I am merely 35 (for the next few weeks lol), but I look back fondly on my
> time with this community. Pov has a place, and as long as we can
> strategically select and implement certain things that we know directly
> influence render package adoption, as evidenced by many out there, Pov will
> live.

I certainly agree with that with all my heart.

>
> Pov was formed under a different precept that governs recent packages,
> primarily this has been discussed above already but put simply it comes
> down to speed, quality and interoperability.

I think this is the Achilles heel of POV-Ray when all, I repeat: all, 
the attention nowadays goes to game development with increasing realism 
(and speed).

>
> Pov largely has the quality, it can have the speed, and it needs the
> interoperability. It has a feature set that is just awesome, and if we can
> get the speed and interop part down, and get the word out, I think we will
> be golden.
>
>>
>> Again, I am not convinced personally that POV-Ray "slowly withers" but I
>> would like to hear other opinions on that.
>>
>
> If you do not think so, go to Google trends, type in pov-ray, select from
> 2004 until today.
>
> Its dire, man, dire.
>
> It has decreased 100x.

That is indeed quite true in the world at large; I was thinking about 
the - admittedly small - POV-Ray community. It would be worthwhile to 
dig up the discussions there have been upon this topic some years ago, 
when this was mentioned too. I don't remember exactly what was mentioned 
as causes for this but I think there was complains about "slowness", 
"involved/difficult/old-fashioned script programming", "ray-tracing not 
fashionable any more compared to other modelling developments", "useless 
for game development", and more such. They are probably still true for a 
large part of the modelling world. POV-Ray is for aficionados, the 
elite! :-)

>
>> To me it has opened several artistic doors as it gave me the possibility
>> to express almost perfectly what I dream about.
>>
>
> The worlds you make are pretty dang cool man. :)

Thanks indeed, Ian, much appreciated. The maker of SnowIce is well 
remembered by me ;-)


-- 
Thomas

[Thomas de Groot] Re: Can I pay someone to add this from MegaPov? [3443 days 8 hours and 24 minutes ago]

Tue, 8 Nov 2016 07:43:21 GMT

On 8-11-2016 0:05, [GDS|Enropy] wrote:
> As far as highest bid getting the work, well that is free market economy
> for you. ;-) if someone is willing to pay then they obviously care enough
> about that feature to trade their money for it, which is a completely valid
> exchange.

I don't think I need to explain what I think of free market economy... ;-)

-- 
Thomas

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3443 days 16 hours and 34 minutes ago]

Mon, 7 Nov 2016 23:33:36 GMT

My apologies man, I didn't know the posts were going here as my reader (iOS
NewsTap) was not subbed to this group, I intended no disrespect. :)

Thomas de Groot <tho### [at] degrootorg> wrote:
> Why is our community in trouble? It seems to me that over the last 
> couple of years at least there has been quite a lot of activity by our 
> respected POV-Ray developers.
> 

Beyond the google trends result that the searches for pov have decreased
100x since 2004, I am considering the volume of posts, new/extant pages
about pov or with pov content, places I see Pov mentioned around the web,
etc compared to the same from around lets say, 1994-1998 or so.

There were once numerous Pov webrings, many new folks coming through all
the time, loads of IRC activity, all kinds of unofficial patches,
specifically pov supporting shareware...substantially all of that
has...ebbed. :'-(

Us old guys and the badasses writing the code are all that is left it
seems. I have seen a lot go away over the last twenty something years.

> 
> Maybe...
> 

Anything that we can do which would drive more people to use Pov I am down
for, and I think that will be achieved through having certain (I don't have
a list) features combined with the quality of render, speed and one of the
most important things....having plugins for commonly used modeling packages
that interop with PovRay.

Getting textures from app A to render in pov...thats one hellova sticky
bit. Interop is a big, difficult thing, but ultimately you see that the
fastest growing renderers grow precisely because of the properties I listed
above.

If I am missing anything let me know.

> 
> There has been a drop of activity, mainly on the users side, with the 
> old guard turning away to other activities for instance but maybe also 
> because of age. Maybe that was due to the state-of-the-art of POV-Ray, 
> maybe not; I seem to remember some discussion about this in the past. 
> However, there has also been some new additions to the community, and I 
> think that - coming out of the "experimental" (?) stage - images have 
> become more complex/involved and/or needing more time and thought to be 
> composed. It certainly has evolved for me like that. And talking of age, 
> my own POV-Ray production is slowly dwindling over the years and that is 
> largely due to those same years accumulating on my shoulders. At 
> seventy, I am not as productive any more as I was twenty years ago.
> 

I am merely 35 (for the next few weeks lol), but I look back fondly on my
time with this community. Pov has a place, and as long as we can
strategically select and implement certain things that we know directly
influence render package adoption, as evidenced by many out there, Pov will
live.

Pov was formed under a different precept that governs recent packages,
primarily this has been discussed above already but put simply it comes
down to speed, quality and interoperability.

Pov largely has the quality, it can have the speed, and it needs the
interoperability. It has a feature set that is just awesome, and if we can
get the speed and interop part down, and get the word out, I think we will
be golden.

> 
> Again, I am not convinced personally that POV-Ray "slowly withers" but I 
> would like to hear other opinions on that.
> 

If you do not think so, go to Google trends, type in pov-ray, select from
2004 until today.

Its dire, man, dire.

It has decreased 100x.

> To me it has opened several artistic doors as it gave me the possibility 
> to express almost perfectly what I dream about.
> 

The worlds you make are pretty dang cool man. :)

Ian

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3443 days 17 hours and 2 minutes ago]

Mon, 7 Nov 2016 23:05:57 GMT

I concur in some respects, though keep in mind things for which they might
be willing to accept bounties is obviously completely under the control of
those actually doing the work.

I am not going to argue with them or push them. I will state my case, see
if there is any interest or takers, and go from there.

No one is forcing them to do anything, and at least initially the goal is
low hanging fruit, with discussion around bigger items to see what interest
is for both devs and users, and ultimately the devs calling the shots.

My goal is to both reward he devs and to enable things to be done which
otherwise might not be possible. They spend their time doing this work, and
if a bounty is sufficient to offset some of the personal cost from this, I
am happy to support.

As far as highest bid getting the work, well that is free market economy
for you. ;-) if someone is willing to pay then they obviously care enough
about that feature to trade their money for it, which is a completely valid
exchange.

I am not proposing small bounties either. I advocate serious bounties only;
fair ones, and if a dev and patron agree on a reasonable price for a
reasonable thing, more is the benefit for us all, as even those who did not
or could not pay benefit, and the devs get tangible rewards beyond a warm
fuzzy feeling. :)

I think though if this did take off and folks saw there is money here, it
could increase the number of devs.

On a personal note, any bounty I pay will also have a donation to the Pov
Team/org as a whole if such a thing is possible. Do they have a Patreon
page or something? I want to make sure the whole org benefits.

Maybe in future bounties there could be a % to implementing dev (the
negotiated bounty) with a fixed percent *on top of that* which goes to the
pov org overall.

Ian

Thomas de Groot <tho### [at] degrootorg> wrote:
> [Devils Advocate]
> 
> Yes, but...
> 
> Consider: (1) One day = 24 hours; (2) Number of people working on 
> POV-Ray << infinity; (3) Highest bid gets development priority; (4) 
> Regular POV-Ray development will slow down / be put on hold for lack of 
> manpower/womanpower.
> 
> Possible/likely scenario?
> 
> [/devils Advocate]
>

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3443 days 17 hours and 17 minutes ago]

Mon, 7 Nov 2016 22:50:56 GMT

clipka <ano### [at] anonymousorg> wrote:
> 
> From what I can see in that project's documentation, it only implemented
> surface shaders, not displacement shaders.
> 
> Support for true displacement is extremely hard to implement for
> arbitrary primitives. Probably the only reasonable way to get there is
> via tesselation, i.e. converting arbitrary geometry into meshes.
> 
> Parallax mapping might be a reasonably good alternative for various use
> cases.
> 

Ah, that's my luck.

I have seen some macros that allow some form of surface deformation, and
then the deformations from pigment patterns I have seen folks use seem
nice, but my goal would be something altogether more powerful and more
fully fleshed out, while occurring internally instead of by macro. 

Any reasonable progress in that direction I would be happy to add my
patronage to. I am a huge fan of true displacement. :)

> 
> Progressive tracing should be easy enough to implement once the internal
> architecture has been sufficiently cleaned up. MCPov had it, and it's
> firmy on the ToDo list for UberPOV.
> 

This is a good sign then, and perhaps due to it already being on the list
and having a source backing somewhat in place would serve to move this up
the list.

Im going to check out the other posts I missed due to nit being subbed to
this group previously, then collect what I have from those and see if we
can get some kind of rather short (less than 5 items) that are reasonable,
sizable, and that we can take and move forward on with coming up with some
first stab at with building some kind of system to go forward with.

Ian

[Yvo Smellenbergh] UberPOV-Development-Branch-1.37.1.1-alpha.886115... [3443 days 23 hours and 37 minutes ago]

Mon, 7 Nov 2016 16:31:08 GMT

At last, with the help from the great master 'clipka', the most recent 
version of UberPOV is now available for Mac.

Minimum system is 10.7.5, 64-bit (no support for 32-bit)

http://megapov.inetart.net/povrayunofficial_mac/uberpov.html

Yvo

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


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[Thomas de Groot] Re: Can I pay someone to add this from MegaPov? [3447 days 3 hours and 43 minutes ago]

Fri, 4 Nov 2016 12:24:20 GMT

On 3-11-2016 17:30, [GDS|Enropy] wrote:
> Wow no comments huh? Lol... I thought someone would have something to say
> at least.

Well, my answer as Devil's Advocate above was not considered to be 
trivial to me :-) as I raise a practical as well as a moral issue, all 
good faith intentions being acknowledged of course.

>
> This just motivates me more to personally take out strategic bounties for
> stuff that might make Pov more attractive as a 3rd party rendering plugin
> at the least...whatever it takes to keep it alive...it looks like our
> community is in trouble...not nearly as active as the early 90s...not much
> new blood, not much new in the way of IDE/Modelers...

Why is our community in trouble? It seems to me that over the last 
couple of years at least there has been quite a lot of activity by our 
respected POV-Ray developers.

>
> Im going to need to think about what to offer payment for.
> I am not rich but I am willing to do my part in thanks to those whose
> efforts have given us all, freely, what I feel is one of the most
> interesting, useful and beautiful rendering packages out there.
>
> Maybe a gofundme or patreon page for pov would stimulate dev work and
> attract new devs, and with certain features maybe attract new users.

Maybe...

>
> I have seen a huge drop off in activity over the decades and want to affect
> change. Bounties is the best answer I have come up with so far. For me
> Glows are just the start. I am going to invest in this, by damn.

There has been a drop of activity, mainly on the users side, with the 
old guard turning away to other activities for instance but maybe also 
because of age. Maybe that was due to the state-of-the-art of POV-Ray, 
maybe not; I seem to remember some discussion about this in the past. 
However, there has also been some new additions to the community, and I 
think that - coming out of the "experimental" (?) stage - images have 
become more complex/involved and/or needing more time and thought to be 
composed. It certainly has evolved for me like that. And talking of age, 
my own POV-Ray production is slowly dwindling over the years and that is 
largely due to those same years accumulating on my shoulders. At 
seventy, I am not as productive any more as I was twenty years ago.

>
> Pov **cannot** be allowed to slowly wither; it is responsible for my entire
> 23yr career in software engineering (I'm now a VP), my meeting my wife (in
> art appreciation class due to death-metal, a presentation on Gilles Tran
> Pov work, and a scene I made in Pov) and supporting my family (because Pov
> taught me to code)...I *owe* Pov and team...

Again, I am not convinced personally that POV-Ray "slowly withers" but I 
would like to hear other opinions on that.

>
> Who else feels this way?
> How has Pov changed your life?
> Has it introduced you to programming, helped you visualize your thesis, got
> you into a career in 3d art, or what?
>
> I cannot be the only one for whom Pov has opened professional, artistic and
> intellectual doors.

To me it has opened several artistic doors as it gave me the possibility 
to express almost perfectly what I dream about.

>
> Ian
>

-- 
Thomas

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3447 days 23 hours and 37 minutes ago]

Thu, 3 Nov 2016 16:30:37 GMT

Wow no comments huh? Lol... I thought someone would have something to say
at least.

This just motivates me more to personally take out strategic bounties for
stuff that might make Pov more attractive as a 3rd party rendering plugin
at the least...whatever it takes to keep it alive...it looks like our
community is in trouble...not nearly as active as the early 90s...not much
new blood, not much new in the way of IDE/Modelers...

Im going to need to think about what to offer payment for.
I am not rich but I am willing to do my part in thanks to those whose
efforts have given us all, freely, what I feel is one of the most
interesting, useful and beautiful rendering packages out there.

Maybe a gofundme or patreon page for pov would stimulate dev work and
attract new devs, and with certain features maybe attract new users.

I have seen a huge drop off in activity over the decades and want to affect
change. Bounties is the best answer I have come up with so far. For me
Glows are just the start. I am going to invest in this, by damn.

Pov **cannot** be allowed to slowly wither; it is responsible for my entire
23yr career in software engineering (I'm now a VP), my meeting my wife (in
art appreciation class due to death-metal, a presentation on Gilles Tran
Pov work, and a scene I made in Pov) and supporting my family (because Pov
taught me to code)...I *owe* Pov and team...

Who else feels this way?
How has Pov changed your life?
Has it introduced you to programming, helped you visualize your thesis, got
you into a career in 3d art, or what?

I cannot be the only one for whom Pov has opened professional, artistic and
intellectual doors.

Ian

[Thomas de Groot] Re: Can I pay someone to add this from MegaPov? [3450 days 3 hours and 46 minutes ago]

Tue, 1 Nov 2016 12:21:29 GMT

On 1-11-2016 9:38, [GDS|Enropy] wrote:
> For everyones general information, I think bounties like this are a great
> way not only to get new features, but most especially to say "thanks" to
> the folks who put in work making PovRay what it is.
>

[Devils Advocate]

Yes, but...

Consider: (1) One day = 24 hours; (2) Number of people working on 
POV-Ray << infinity; (3) Highest bid gets development priority; (4) 
Regular POV-Ray development will slow down / be put on hold for lack of 
manpower/womanpower.

Possible/likely scenario?

[/devils Advocate]

-- 
Thomas

[clipka] Re: Can I pay someone to add this from MegaPov? [3450 days 6 hours and 42 minutes ago]

Tue, 1 Nov 2016 09:25:20 GMT

Am 01.11.2016 um 09:38 schrieb [GDS|Enropy]:

> Once this feature is in I want to look at true displacement, which will be
> a ton of work and I won't be able to fund it alone. I think TD would buy a
> lot for both the package and the community as a whole.
> 
> There was at least one PovRay modification that supported  true
> displacement, but the way it was accomplished was to make Pov conform to
> some degree with the Renderman SL standard, and if I recall correctly it
> broke entirely with the way pov handles materials (not the pov term, but
> general).
> 
> It is dead but the source lives on courtesy of Archive.org:
>
https://web.archive.org/web/20090103185310/http://www.aetec.ee/fv/vkhomep.nsf/pages/povman2

From what I can see in that project's documentation, it only implemented
surface shaders, not displacement shaders.

Support for true displacement is extremely hard to implement for
arbitrary primitives. Probably the only reasonable way to get there is
via tesselation, i.e. converting arbitrary geometry into meshes.

Parallax mapping might be a reasonably good alternative for various use
cases.


> - A reasonable alternative to GPU raytracing is "progressive raytracing", a
> quick google search even gets you articles stating that this is far less
> complex to do than GPU but is much faster than normal RT and is advocated
> as either an alternative to GPU RT or an intermediate point between normal
> RT and a GPU implementation.

Progressive tracing should be easy enough to implement once the internal
architecture has been sufficiently cleaned up. MCPov had it, and it's
firmy on the ToDo list for UberPOV.

[INVALID ADDRESS] Re: Can I pay someone to add this from MegaPov? [3450 days 7 hours and 30 minutes ago]

Tue, 1 Nov 2016 08:38:04 GMT

For everyones general information, I think bounties like this are a great
way not only to get new features, but most especially to say "thanks" to
the folks who put in work making PovRay what it is.

I am very excited for the opportunities this opens up for everyone.

Once this feature is in I want to look at true displacement, which will be
a ton of work and I won't be able to fund it alone. I think TD would buy a
lot for both the package and the community as a whole.

There was at least one PovRay modification that supported true
displacement, but the way it was accomplished was to make Pov conform to
some degree with the Renderman SL standard, and if I recall correctly it
broke entirely with the way pov handles materials (not the pov term, but
general).

It is dead but the source lives on courtesy of Archive.org:
https://web.archive.org/web/20090103185310/http://www.aetec.ee/fv/vkhomep.nsf/pages/povman2

Povman is based on MP 1.1, and Vahur Krouverk was the author.

Obviously we would want to keep the way pov handles materials in SDL, but
also allow true displacement as seen in Renderman. I don't know what this
would entail specifically but I would feel safe betting it would be
nontrivial work.

I am not advocating full RM spec compliance, only hijacking the
displacement code from PovMan in some form, preferably without having to
use a shader compiler.

I would like to know how many folks would like to see true displacement
ported over because like I said I can't fund that one alone (at least not
in a single shot).

If there isn't much interest (which frankly would shock me) then it
wouldn't even be worth trying to size the work...but conversely if the
interest is great, then there may be some merit at least in investigation
of the idea.

Other things which might be useful:

- OpenCL/GPU. This has been talked to death but because of the complexity
perhaps a large enough bounty would be sufficiently motivating and provide
a good ROI for the team.

- A reasonable alternative to GPU raytracing is "progressive raytracing", a
quick google search even gets you articles stating that this is far less
complex to do than GPU but is much faster than normal RT and is advocated
as either an alternative to GPU RT or an intermediate point between normal
RT and a GPU implementation.

- Ability to "scan" objects into a distance based resolution adaptive mesh
instead of rendering the object as normal, which might speed up render. (I
know marching triangles macros exist, would an internal implementation be
faster?)

- Navier-Stokes flow, compressible and incompressible implemented as a
primitive. So if you place the primitive in a hollow hemisphere it would
naturally fill it, or if you put it in a HF valley with rocks and such it
would fill it to the Y position of the primitive and "flow" around the
rocks, making eddies and ripples and such. Flow direction would be a
vector, fluid would naturally fill whatever was around it as well.

- Enhancements to volumetric rendering, so media behaves
consistently/predictably regardless of container volume and/or scale. Right
now making a good looking variable density fog or cloud can get a bit weird
and it is difficult to predict the outcome of any given input. Having some
kind of distance based resolution may enhance speed as well. Perhaps the
volumetric rendering task can be sent to the GPU alone.

- Implement a plugin based architecture for pov, so new features could be
added without having to rework the whole application each time. I have
solved many problems using plugin based architecture, and am quite a fan of
it. If done correctly this might allow Pov to get more features faster, but
would take a lot of work to do initially.

Ian

[clipka] Re: Can I pay someone to add this from MegaPov? [3451 days 5 hours and 29 minutes ago]

Mon, 31 Oct 2016 10:38:45 GMT

Am 31.10.2016 um 00:16 schrieb [GDS|Entropy] in povray.advanced-users:

> I was wondering (hoping) that I could pay someone to add Glows to UberPov,
> and include enough implementation info via comments or whatever that
> whoever in the future could easily forward this to the next version when 4
> comes out. If you are interested Clipka, even better. ;-)

I've just noticed to my surprise that you're apparently not the guy who
had requested the very same MegaPOV feature just a few weeks ago on the
povray.macintosh newsgroup, so I've decided to use this occasion for a
shameless plug or two:


While I love working on POV-Ray and UberPOV as a hobby, and will quite
certainly continue to do so no matter what I get out of it, I'm not
above taking donations that allow me to spend more time on this hobby --
nor am I above taking bribes to prioritize my ToDo list.

So to anyone wishing to back up Ian's (aka GDS|Entropy) motion to get
the MegaPOV "glow" feature implemented in UberPOV ASAP, feel free to
place a bounty on the corresponding GitHub issue via Bountysource:

https://www.bountysource.com/issues/38809617-port-megapov-s-glow-feature-to-uberpov


In related news, anyone inclined to send some round tuits my way for
general POV-Ray and UberPOV development is happily invited to take a
look at https://salt.bountysource.com/teams/uberpov.

[Mr] Re: UberPOV is back [3499 days 2 hours and 43 minutes ago]

Tue, 13 Sep 2016 13:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 01.09.2016 um 16:06 schrieb Mr:
>
> >>> -Minnaert?
> >>
> >> Nope. Again, to the contrary: Minnaert also makes the diffuse component
> >> fall off at shallower angles.
> >
> > Blender's implementation can also do the opposite: lightening faces as their
> > normals get perpendicular to the viewing direction, kind of like oren Nayer also
> > does , but orders of magnitude stronger.  (" if Dark is 1 you get exactly the
> > Lambertian result. Higher darkness values will darken the center of an object
> > (where it points towards the viewer). Lower darkness values will lighten the
> > edges of the object, making it look somewhat velvet")
>
> I must confess that I'm digging into the Minnaert model only just now.
> And yes, it seems indeed to be capable of doing something like the
> Oren-Nayar and Lommel-Seeliger models.
>
> > So maybe we could say that Lommel-Seeliger  is a good model to emulate all
> > darkness values of Blender Minnaert below 1 wile values above could switch to a
> > darkening slope_map/aoi pattern ?
>
> If you want to emulate Blender's Minnaert in POV-Ray, wait for a couple
> of hours until the next UberPOV release ;)
>
> > And Brilliance parameter would be better to emulate Fresnel as it's more light
> > dependant than viewing angle dependant???
>
> The Brilliance parameter is primarily a poor hack with no physical
> legitimation. I suspect the best way to emulate it would be with
> something like an aoi pattern. While it might indeed have been used as a
> poor man's attempt at approximating a fresnel term, it would have
> succeeded in that only for the outgoing light, ingoing that there should
> be a symmetric term for the incoming light.
>
> (After some research, I have a hunch that the brilliance parameter
> /might/ actually have originated as a failed attempt to implement the
> Minnaert model. But that's just speculation, and it's probably far too
> late to find out the truth about it.)
>
> > Anyway, at the moment I meet a bigger issue, as I see no variation when trying
> > to use the two new models in pov, are they confirmed to work in your Windows 64
> > build?
>
> They should be working fine in UberPOV 1.37.1.1-alpha.8756754, but I'll
> check again.
>
> > The Minnaert shader in POV was the topic of this work:
> >
http://news.povray.org/povray.binaries.images/thread/%3C3f6ccdf7%40news.povray.org%3E/
> >
> > Has it been used for this feature or can it still be added to all the options?
>
> I didn't even know about Kevin's work until right now that you've
> mentioned it (and I'm not sure whether I would be able to dig up his
> code on the Internet). I had even started on my own Minnaert
> implementation already.

Thanks for all the work,  I tried again and it works (I was using a bad version
/#patch syntax...

Three shaders Oren_nayar, Lomel_selliger, minnaert work well. To be nitpicky, I
felt that the minnaert at a value of 2 which is its Blender Maximum value, the
result looked less contrasted than Blender internal renderer. That is to say, in
Blender, faces away from camera appeared lighter while normals facing the camera
were darker than pov result but the overall behaviour is a much closer result
than what we had so far !

How would we use the second fresnel outgoing term ?

[William F Pokorny] Patches and git / github with branches. [3499 days 2 hours and 49 minutes ago]

Tue, 13 Sep 2016 13:18:58 GMT

I'm relatively new to git & github. I thought I'd ramble a minute  about 
how I find myself keeping individual branches for features and fixes.

Branches, both published to github(1) and local to my computer, are kept 
current with the povray 3.7.1 master branch. In my local environment I 
now periodically create my own version(branch) of povray where I 'git 
pull' in the features and fixes I want for what I am working upon.

The feature and fix branches can be pulled from others too so long as 
they've been kept current with the 3.7.1 master branch. This I did the 
first time this morning with Christoph's proposed potential pattern.

Having a history with other code control systems I was initially merging 
branches together and back into my personal version branch. I wasn't 
keeping branches around - or even creating many.

Not creating & maintaining branches made it a good deal harder to stay 
aligned with the povray 3.7.1 master branch; Harder to later isolate a 
particular feature/fix for a pull request or removal; Harder to cook up 
the version of povray I want in the moment.

Guess I'm saying git branches are cool. :-)

Bill P.

(1) - What I think reasonably solid & perhaps of use to others.

[Thomas de Groot] Re: UberPOV small glitch? [3503 days 9 hours and 22 minutes ago]

Fri, 9 Sep 2016 06:46:01 GMT

On 8-9-2016 18:04, clipka wrote:
> Coincidently, when I read your post I was just about to wrap up some
> slight change to the reserved words mechanism, with the intention to
> make it easier to maintain. It turns out that the way I designed it, the
> modified mechanism would have been even _less_ robust against this
> particular case; so you've just prevented me from submitting
> ill-conceived code ;)
>
>
> I think I'll leave this unfixed in UberPOV for now, as it doesn't do any
> real harm, and wait until that mentioned change (in a more robust
> variant) trickles in from official POV-Ray.
>

Excellent! Glad to be of help ;-)

In future, I shall point to the correct version number as requested. I 
have been sadly remiss in the matter. :-)

-- 
Thomas

[clipka] Re: UberPOV small glitch? [3504 days and 3 minutes ago]

Thu, 8 Sep 2016 16:04:57 GMT

Am 08.09.2016 um 17:33 schrieb clipka:

> Unfortunately that version doesn't come with a theory attached as to
> what might be going wrong there. Although it almost certainly has to do
> with the fact that the "Z_TOKEN" is the very last entry in the list of
> all reserved words.

Found the culprit. Apparently there was some disagreement between the
GUI and the parser whether the "#persistent" feature should be enabled,
causing them to come up with different values for the length of the list
of reserved words. While the parser actually compiled 595 entries into
the list, the GUI was thoroughly convinced it had to retrieve only 594
entries, and thus failed to retrieve the last entry.

Coincidently, when I read your post I was just about to wrap up some
slight change to the reserved words mechanism, with the intention to
make it easier to maintain. It turns out that the way I designed it, the
modified mechanism would have been even _less_ robust against this
particular case; so you've just prevented me from submitting
ill-conceived code ;)


I think I'll leave this unfixed in UberPOV for now, as it doesn't do any
real harm, and wait until that mentioned change (in a more robust
variant) trickles in from official POV-Ray.

[clipka] Re: UberPOV small glitch? [3504 days and 34 minutes ago]

Thu, 8 Sep 2016 15:33:47 GMT

Am 08.09.2016 um 14:08 schrieb Thomas de Groot:
> A pov file in latest UberPOV containing e.g.  x+y+z or max.z  shows the
> z as a black parameter instead of the violet shown by x or y.

Given how many branches I'm currently juggling in parallel, I wish
people would be more precise about that "latest" version they're using ;)

I tend to presume you're talking about one of the
1.37.1.1-alpha.8767927+av5 binaries for Windows.

Unfortunately that version doesn't come with a theory attached as to
what might be going wrong there. Although it almost certainly has to do
with the fact that the "Z_TOKEN" is the very last entry in the list of
all reserved words.


> It does not seem to influence parsing or rendering though.

I wouldn't be so sure about that just yet; not until you have thoroughly
tested it both _inside_ and _outside_ user-defined functions.

[Thomas de Groot] UberPOV small glitch? [3504 days 3 hours and 59 minutes ago]

Thu, 8 Sep 2016 12:08:53 GMT

A pov file in latest UberPOV containing e.g.  x+y+z or max.z  shows the 
z as a black parameter instead of the violet shown by x or y.

It does not seem to influence parsing or rendering though.

-- 
Thomas

[LanuHum] Re: UberPOV is back [3507 days 21 hours and 33 minutes ago]

Sun, 4 Sep 2016 18:35:00 GMT

Last uberpov had abnormalities in height_field. I forgot to report it. I'll
check out the new version.
I'll report on the results.

[clipka] Re: UberPOV is back [3509 days 20 hours and 2 minutes ago]

Fri, 2 Sep 2016 20:06:10 GMT

Am 01.09.2016 um 19:08 schrieb Le_Forgeron:
> Le 01/09/2016 Ã  18:03, clipka a Ã©crit :
>> Am 01.09.2016 um 14:14 schrieb Mr:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> Am 01.09.2016 um 10:29 schrieb Mr:
>>>>> clipka <ano### [at] anonymousorg> wrote:
>>>>>> FYI, I've just put UberPOV back on the tracks.
>>>>>>
>>>>>> The current development version includes all the latest and greatest
>>>>>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>>>>>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>>>>>
>>>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>>>>
>>>>> Are HG POV goodies also candidates to be merged one day?
>>>>
>>>> There are some Hg-Povray features that I've already set my eyes on, yes.
>>>> But I haven't found the time yet to steal(*) them.
>>>>
>>>> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
>>>> have to label those features as original UberPOV features. And I might
>>>> actually use different syntax.)
> 
> I never understood that proposal, or how to use it, from the coding side.

From the "[patch] coding side" it might be as simple as borrowing the
corresponding code from UberPOV.

From the "[scene] coding side" it is not fundamentally different from
the way we're already specifying what POV-Ray version a scene needs:

    // (1) State that you use patches conforming to that proposal,
    //     and what baseline of official POV-Ray features your scene
    //     is making use of:
    #version unofficial patch 3.71;

    // (2a) State what individual additional features your scene is
    //      making use of, and the minimum versions thereof:
    #patch "upov-oren_nayar" 0.9;
    #patch "wfpokorny-density_file-refine" 1.10;

Given this header, the scene will render fine on any patched version of
POV-Ray that intentionally supports the Oren-Nayar shading with the same
syntax as UberPOV, as well as the density file extensions originally
developed by William F. Pokorny -- no matter whether that patched
version of POV-Ray happens to be UberPOV, or an entirely different patch
collection that just cherry-picked these two features, as long as it
does adhere to the `unofficial patch` proposal.

The proposal also allows to choose alternative scene code depending on
what patches are available. For instance, suppose you know that two
different patched versions of POV-Ray provide an implementation of the
Oren-Nayar shading model, but use different syntax. You could then
define a texture as follows:

    #declare MyFinish = finish {
      #if (patch("upov-oren_nayar"))
        // UberPOV's current Oren-Nayar implementation interprets
        // the parameter as the sigma
        oren_nayar SIGMA
      #elseif (patch("snugglepov-oren_nayar"))
        // SnugglePOV happens to use the same keyword, but interprets
        // the parameter as the square of sigma
        oren_nayar SIGMA*SIGMA
      #end
    }

This is actually the part of the `unofficial patch` proposal that I find
the most useful: Back when I was still juggling with POV-Ray 3.7,
MegaPOV and MCPov, I found it frustrating that I couldn't have my scenes
auto-detect whether they were running on MCPov (in which case I would
want blurred reflections, but would also have to use different diffuse
values because MCPov got them wrong by a factor of 2, and would have to
define light sources as emissive spheres) or one of the others (in which
case I would want radiosity, and use classic light sources).

> And I do not really care, as I use only the official povray and hgpovray, my little
pet.

For such cases, the `unofficial patch` proposal also has something in store:

    // (1) State that your scene is designed for a patched version
    //     of POV-Ray supporting the `unofficial patch` proposal,
    //     and what baseline of official POV-Ray features your scene
    //     is making use of:
    #version unofficial patch 3.71;

    // (2b) State what patched version of POV-Ray your scene is
    //      designed for:
    #patch "upov" 137.1;

Given this header, the scene will render fine on UberPOV 1.37.1.1 or
higher -- *OR* on any other patched version of POV-Ray that includes
support for the full set of UberPOV 1.37.1.1's features.

>>> I, for one would be very happy for it, hoping the original author is not
>>> offended, and I'm sure he can be credited somewhere properly for his
>>> contribution...
>>
>> He certainly would get credited. And as for being offended, I have some
>> hope that Jerome's wrath would be contained within a reasonably small
>> bounding box ;)
>>
> Since the start of the refactoring (3 years ago?), I'm waiting for the code
> to stabilize (in term of change to C++ objects) before moving the changes
> of hg-povray in compatible code. I usually check once a year, at summer holiday,
> but it is not easy. (and the change of directory hierarchy is not friendly with
> automerging tools)

3 years ago was 2013 -- the year 3.7.0 was finally released (in December).

No, refactoring didn't start 3 years ago -- it started after 3.6.1 (or
maybe even before that, in a separate branch), and was interrupted only
briefly in 2013 to get a stable version out the door, after refactoring
had changed the architecture enough to be able to implement
single-machine symmetric multiprocessing support for all features.

Refactoring was never meant to stop there: Distributed rendering was the
original goal of the refactoring, and still is one of the goals. And
another goal has been added: To turn POV-Ray's rendering engine into
something that can be used as a library.

Changes to the directory hierarchy have been -- and to some degree still
are -- a necessary evil of that ongoing process, as it greatly
simplifies the process of partitioning the code into clear-cut modules.

As for tracking moved files, I was pleasantly surprised by the
capabilities of Atlassian's SourceTree in this respect when I recently
brought UberPOV up to date -- though I should say that I merged in
stages, making sure to "pause" right before and after each commit that
moved around any files, and then squashed those stages into a single
commit. SourceTree is free, supports both Git and Mercurial, and is
available for Windows and OS X.

I'm also making heavy use of BeyondCompare, without which I couldn't
code a single thing. Besides using it as an external 3-way merge tool
for SourceTree, I'm also using it to sync my actual working directory
with the so-called "working directory" of my local repo, which I'm not
actually working on directly. It is available for Windows, OS X and
Linux, and although it costs a few bucks, I'd say it is worth every cent
of the Pro version's $60.

> So far my plan is to finish the normal computation of nurbs in hg-povray
> (something where reading M. S. Floater in text is a must go, and no,
> I'm not going for approximation), then (when more time become available
> here), trying to merge the head of master povray into hg-povray...
> unless there is another refactoring happening just 2 weeks before I would
> have merged).

Don't expect refactoring to stop any time soon; there's still a shitload
of work to do until we have nice clean C++ code.

[Le Forgeron] Re: UberPOV is back [3510 days 22 hours and 59 minutes ago]

Thu, 1 Sep 2016 17:08:30 GMT

Le 01/09/2016 Ã  18:03, clipka a Ã©crit :
> Am 01.09.2016 um 14:14 schrieb Mr:
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 01.09.2016 um 10:29 schrieb Mr:
>>>> clipka <ano### [at] anonymousorg> wrote:
>>>>> FYI, I've just put UberPOV back on the tracks.
>>>>>
>>>>> The current development version includes all the latest and greatest
>>>>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>>>>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>>>>
>>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>>>
>>>> Are HG POV goodies also candidates to be merged one day?
>>>
>>> There are some Hg-Povray features that I've already set my eyes on, yes.
>>> But I haven't found the time yet to steal(*) them.
>>>
>>> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
>>> have to label those features as original UberPOV features. And I might
>>> actually use different syntax.)

I never understood that proposal, or how to use it, from the coding side.

And I do not really care, as I use only the official povray and hgpovray, my little
pet.

>>
>> I, for one would be very happy for it, hoping the original author is not
>> offended, and I'm sure he can be credited somewhere properly for his
>> contribution...
> 
> He certainly would get credited. And as for being offended, I have some
> hope that Jerome's wrath would be contained within a reasonably small
> bounding box ;)
> 
Since the start of the refactoring (3 years ago?), I'm waiting for the code to
stabilize (in term of change to C++ objects) before moving the changes of hg-povray in
compatible code. I usually check once a year, at summer holiday, but it is not easy.
(and the change of directory hierarchy is not friendly with automerging tools)

I tried to write the nurbs in both, but it turns out to be painful to maintain. Not
something I'm going to do again.

So far my plan is to finish the normal computation of nurbs in hg-povray (something
where reading M. S. Floater in text is a must go, and no, I'm not going for
approximation),
then (when more time become available here), trying to merge the head of master povray
into hg-povray... unless there is another refactoring happening just 2 weeks before I
would have merged).

Your evolution of ovus has been made, but got little echo.

And I'm probably late also on some documentation too.

[clipka] Re: UberPOV is back [3510 days 23 hours and 33 minutes ago]

Thu, 1 Sep 2016 16:35:14 GMT

Am 01.09.2016 um 16:06 schrieb Mr:

>>> -Minnaert?
>>
>> Nope. Again, to the contrary: Minnaert also makes the diffuse component
>> fall off at shallower angles.
> 
> Blender's implementation can also do the opposite: lightening faces as their
> normals get perpendicular to the viewing direction, kind of like oren Nayer also
> does , but orders of magnitude stronger.  (" if Dark is 1 you get exactly the
> Lambertian result. Higher darkness values will darken the center of an object
> (where it points towards the viewer). Lower darkness values will lighten the
> edges of the object, making it look somewhat velvet")

I must confess that I'm digging into the Minnaert model only just now.
And yes, it seems indeed to be capable of doing something like the
Oren-Nayar and Lommel-Seeliger models.

> So maybe we could say that Lommel-Seeliger  is a good model to emulate all
> darkness values of Blender Minnaert below 1 wile values above could switch to a
> darkening slope_map/aoi pattern ?

If you want to emulate Blender's Minnaert in POV-Ray, wait for a couple
of hours until the next UberPOV release ;)

> And Brilliance parameter would be better to emulate Fresnel as it's more light
> dependant than viewing angle dependant???

The Brilliance parameter is primarily a poor hack with no physical
legitimation. I suspect the best way to emulate it would be with
something like an aoi pattern. While it might indeed have been used as a
poor man's attempt at approximating a fresnel term, it would have
succeeded in that only for the outgoing light, ingoing that there should
be a symmetric term for the incoming light.

(After some research, I have a hunch that the brilliance parameter
/might/ actually have originated as a failed attempt to implement the
Minnaert model. But that's just speculation, and it's probably far too
late to find out the truth about it.)

> Anyway, at the moment I meet a bigger issue, as I see no variation when trying
> to use the two new models in pov, are they confirmed to work in your Windows 64
> build?

They should be working fine in UberPOV 1.37.1.1-alpha.8756754, but I'll
check again.

> The Minnaert shader in POV was the topic of this work:
>
http://news.povray.org/povray.binaries.images/thread/%3C3f6ccdf7%40news.povray.org%3E/
> 
> Has it been used for this feature or can it still be added to all the options?

I didn't even know about Kevin's work until right now that you've
mentioned it (and I'm not sure whether I would be able to dig up his
code on the Internet). I had even started on my own Minnaert
implementation already.

[clipka] Re: UberPOV is back [3511 days and 4 minutes ago]

Thu, 1 Sep 2016 16:03:37 GMT

Am 01.09.2016 um 14:14 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 01.09.2016 um 10:29 schrieb Mr:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> FYI, I've just put UberPOV back on the tracks.
>>>>
>>>> The current development version includes all the latest and greatest
>>>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>>>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>>>
>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>>
>>> Are HG POV goodies also candidates to be merged one day?
>>
>> There are some Hg-Povray features that I've already set my eyes on, yes.
>> But I haven't found the time yet to steal(*) them.
>>
>> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
>> have to label those features as original UberPOV features. And I might
>> actually use different syntax.)
> 
> I, for one would be very happy for it, hoping the original author is not
> offended, and I'm sure he can be credited somewhere properly for his
> contribution...

He certainly would get credited. And as for being offended, I have some
hope that Jerome's wrath would be contained within a reasonably small
bounding box ;)

[Mr] Re: UberPOV is back [3511 days 1 hour and 58 minutes ago]

Thu, 1 Sep 2016 14:10:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Since I'm no Blender user, I need to do a bit of guesswork here...

Here is the fast illustrated summary of what's available:

https://www.blender.org/manual/render/blender_render/materials/properties/diffuse_shaders.html

In Blender Internal, you specify both a diffuse and a specular shader plus the
fresnel effect used for the "reflection block" which has nothing to do with the
one you can use in the diffuse, the later acts just as if you put some color_map
to alter object luminosity, darkening it along the vector of the lamp directed
at it.
>
> To the contrary: As you view the surface at a more shallow angle,
> applying a Fresnel term will make the diffuse component fall off; using
> the Lommel-Seeliger model, the diffuse brightness instead intensifies.
>

indeed!... But angles to the lamp vector

> > -Lambert with a Normal input ramp?
in Blender you can also use a color_map along the viewing direction, just like
povray slope_map
specifying the "normal" option makes the gradient apply in viewing direction.
whereas "energy" for instance applies it along the lamp vector

> > -Minnaert?
>
> Nope. Again, to the contrary: Minnaert also makes the diffuse component
> fall off at shallower angles.
>

Blender's implementation can also do the opposite: lightening faces as their
normals get perpendicular to the viewing direction, kind of like oren Nayer also
does , but orders of magnitude stronger.  (" if Dark is 1 you get exactly the
Lambertian result. Higher darkness values will darken the center of an object
(where it points towards the viewer). Lower darkness values will lighten the
edges of the object, making it look somewhat velvet")

So maybe we could say that Lommel-Seeliger  is a good model to emulate all
darkness values of Blender Minnaert below 1 wile values above could switch to a
darkening slope_map/aoi pattern ?

And Brilliance parameter would be better to emulate Fresnel as it's more light
dependant than viewing angle dependant???

Anyway, at the moment I meet a bigger issue, as I see no variation when trying
to use the two new models in pov, are they confirmed to work in your Windows 64
build?

The Minnaert shader in POV was the topic of this work:
http://news.povray.org/povray.binaries.images/thread/%3C3f6ccdf7%40news.povray.org%3E/

Has it been used for this feature or can it still be added to all the options?

Thanks a lot to all devs for your work so far!

[Mr] Re: UberPOV is back [3511 days 3 hours and 53 minutes ago]

Thu, 1 Sep 2016 12:15:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 01.09.2016 um 10:29 schrieb Mr:
> > clipka <ano### [at] anonymousorg> wrote:
> >> FYI, I've just put UberPOV back on the tracks.
> >>
> >> The current development version includes all the latest and greatest
> >> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
> >> (Oren-Nayar and Lommel-Seeliger), and can be found here:
> >>
> >> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
> >
> > Are HG POV goodies also candidates to be merged one day?
>
> There are some Hg-Povray features that I've already set my eyes on, yes.
> But I haven't found the time yet to steal(*) them.
>
> (* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
> have to label those features as original UberPOV features. And I might
> actually use different syntax.)

I, for one would be very happy for it, hoping the original author is not
offended, and I'm sure he can be credited somewhere properly for his
contribution...

[clipka] Re: UberPOV is back [3511 days 4 hours and 55 minutes ago]

Thu, 1 Sep 2016 11:12:40 GMT

Am 01.09.2016 um 10:29 schrieb Mr:
> clipka <ano### [at] anonymousorg> wrote:
>> FYI, I've just put UberPOV back on the tracks.
>>
>> The current development version includes all the latest and greatest
>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>
>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
> 
> Are HG POV goodies also candidates to be merged one day?

There are some Hg-Povray features that I've already set my eyes on, yes.
But I haven't found the time yet to steal(*) them.

(* Since Hg-Povray doesn't support the `unofficial patch` proposal, I'd
have to label those features as original UberPOV features. And I might
actually use different syntax.)

[Thomas de Groot] Re: UberPOV is back [3511 days 4 hours and 59 minutes ago]

Thu, 1 Sep 2016 11:09:05 GMT

On 1-9-2016 12:29, clipka wrote:
> Am 01.09.2016 um 08:54 schrieb Thomas de Groot:
>> By the way, version still:
>>
>> #version unofficial patch 3.7;
>>
>> ?
>
> You /can/ use `unofficial patch 3.7`, but if the scene makes use of any
> features from official POV-Ray introduced after 3.7.0, I'd recommend
> `unofficial patch 3.71`.
>

Of course. Thanks!

-- 
Thomas

[clipka] Re: UberPOV is back [3511 days 5 hours and 7 minutes ago]

Thu, 1 Sep 2016 11:00:58 GMT

Am 01.09.2016 um 10:54 schrieb Mr:

> Though I already spent quite some time to emulate Blender Shaders in POV as they
> get exported, I would like to try to link the exporter to these new shading
> models to find out if it gives closer results.
> 
> Oren Nayar seems straightforward because Blender has its implementation of that
> very model, but what would you say is the closest to Lommel-Seeliger in Blender
> shading models?

Since I'm no Blender user, I need to do a bit of guesswork here...

> -Fresnel?

Nope. Fresnel isn't actually a shading model, but rather a mathematical
term that appears in various shading models. From what I gather on the
internet, it seems that in Blender you can slap it onto every proper
shading model as an option (whether it makes sense or not; I suspect
some models may be sophisticated enough to already account for the
fresnel effect by themselves), and you can do the same in POV-Ray 3.7.1
by using the `fresnel` keyword directly in the `finish` block.

To the contrary: As you view the surface at a more shallow angle,
applying a Fresnel term will make the diffuse component fall off; using
the Lommel-Seeliger model, the diffuse brightness instead intensifies.

> -Lambert with a Normal input ramp?

Dunno. I wasn't able to find any reference to "Normal input ramp" on the
Internet, so someone would have to explain to me what a "Normal input
ramp" is, and how it would be plugged into the Lambert model.

> -Minnaert?

Nope. Again, to the contrary: Minnaert also makes the diffuse component
fall off at shallower angles.


I suspect Lommel-Seeliger is no suitable substitute for any of the
Blender shaders. And if you were to try to go the reverse route and try
to simulate Lommel-Seeliger in Blender, a mix of Lambert and Oren-Nayar
with a particular set of parameter settings (possibly 100% roughness,
but that's just a quick guess) might actually be the best approximation.

[clipka] Re: UberPOV is back [3511 days 5 hours and 38 minutes ago]

Thu, 1 Sep 2016 10:29:45 GMT

Am 01.09.2016 um 08:54 schrieb Thomas de Groot:
> By the way, version still:
> 
> #version unofficial patch 3.7;
> 
> ?

You /can/ use `unofficial patch 3.7`, but if the scene makes use of any
features from official POV-Ray introduced after 3.7.0, I'd recommend
`unofficial patch 3.71`.

[Mr] Re: UberPOV is back [3511 days 7 hours and 13 minutes ago]

Thu, 1 Sep 2016 08:55:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> FYI, I've just put UberPOV back on the tracks.
>
> The current development version includes all the latest and greatest
> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754

Though I already spent quite some time to emulate Blender Shaders in POV as they
get exported, I would like to try to link the exporter to these new shading
models to find out if it gives closer results.

Oren Nayar seems straightforward because Blender has its implementation of that
very model, but what would you say is the closest to Lommel-Seeliger in Blender
shading models?
-Fresnel?
-Lambert with a Normal input ramp?
-Minnaert?

[Mr] Re: UberPOV is back [3511 days 7 hours and 38 minutes ago]

Thu, 1 Sep 2016 08:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> FYI, I've just put UberPOV back on the tracks.
>
> The current development version includes all the latest and greatest
> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754

Are HG POV goodies also candidates to be merged one day?

[Thomas de Groot] Re: UberPOV is back [3511 days 9 hours and 13 minutes ago]

Thu, 1 Sep 2016 06:55:03 GMT

By the way, version still:

#version unofficial patch 3.7;

?

-- 
Thomas

[Thomas de Groot] Re: UberPOV is back [3515 days 9 hours and 27 minutes ago]

Sun, 28 Aug 2016 06:41:10 GMT

That would be interesting and useful indeed.

-- 
Thomas

[clipka] Re: UberPOV is back [3515 days 12 hours and 3 minutes ago]

Sun, 28 Aug 2016 04:05:16 GMT

Am 27.08.2016 um 21:13 schrieb William F Pokorny:

> I reviewed in dome detail what folks have been doing with df3s lately
> and submitted a pull request #81 to enable pigment_map use in the
> density block.
> 
> This will let folks do the image stacking method inside povray with
> something like:
> 
> #declare PigmR  = pigment {
>   image_map { "Red.png"    map_type 0 interpolate 2 } }
> #declare PigmY  = pigment {
>   image_map { "Yellow.png" map_type 0 interpolate 2 } }
> #declare PigmG  = pigment {
>   image_map { "Green.png"  map_type 0 interpolate 2 } }
> #declare PigmC  = pigment {
>   image_map { "Cyan.png"   map_type 0 interpolate 2 } }
> #declare PigmB  = pigment {
>   image_map { "Blue.png"   map_type 0 interpolate 2 } }
> 
> #declare Object00 = object {
>     box { <0.45,0.45,0.00>,<0.55,0.55,1.00> }
>     texture { pigment { rgbt 1 } }
>     hollow on
>     interior {
>         media {
>           emission 3.00
>           samples 30
>           density {
>             gradient z
>             pigment_map {
>               [ 0.0  PigmR ]
>               [ 0.25 PigmY ]
>               [ 0.5  PigmG ]
>               [ 0.75 PigmC ]
>               [ 1.0  PigmB ]
>             }
>           }
>         }
>     }
> }
> 
> I don't see any reason not to allow it & it works in my testing, but I'm
> also a bit surprised it was not already enabled in the code?

I don't see any obvious reason either, but I've learned that doesn't
mean anything, especially when talking about the parser. There might be
something dark and sinister lurking in the depths.

I'd feel a lot more compfortable if, for the time being, you'd just
enable `image_map` in `density{}` statements.

[William F Pokorny] Re: UberPOV is back [3515 days 20 hours and 54 minutes ago]

Sat, 27 Aug 2016 19:13:51 GMT

On 08/26/2016 09:26 AM, clipka wrote:
> Am 26.08.2016 um 13:45 schrieb William F Pokorny:
>
> Speaking of density files -- since you've been dealing with those
> recently, how would you feel about implementing a 3-channel RGB variant?
> Something akin to `image_map` but in 3D? I have a hunch that some people
> might like to have such a thing, but I currently don't find the time myself.
>

I'll put it on my todo list & certainly think about it.

I reviewed in dome detail what folks have been doing with df3s lately 
and submitted a pull request #81 to enable pigment_map use in the 
density block.

This will let folks do the image stacking method inside povray with 
something like:

#declare PigmR  = pigment {
   image_map { "Red.png"    map_type 0 interpolate 2 } }
#declare PigmY  = pigment {
   image_map { "Yellow.png" map_type 0 interpolate 2 } }
#declare PigmG  = pigment {
   image_map { "Green.png"  map_type 0 interpolate 2 } }
#declare PigmC  = pigment {
   image_map { "Cyan.png"   map_type 0 interpolate 2 } }
#declare PigmB  = pigment {
   image_map { "Blue.png"   map_type 0 interpolate 2 } }

#declare Object00 = object {
     box { <0.45,0.45,0.00>,<0.55,0.55,1.00> }
     texture { pigment { rgbt 1 } }
     hollow on
     interior {
         media {
           emission 3.00
           samples 30
           density {
             gradient z
             pigment_map {
               [ 0.0  PigmR ]
               [ 0.25 PigmY ]
               [ 0.5  PigmG ]
               [ 0.75 PigmC ]
               [ 1.0  PigmB ]
             }
           }
         }
     }
}

I don't see any reason not to allow it & it works in my testing, but I'm 
also a bit surprised it was not already enabled in the code?

Bill P.

[clipka] Re: UberPOV is back [3517 days 2 hours and 41 minutes ago]

Fri, 26 Aug 2016 13:26:27 GMT

Am 26.08.2016 um 13:45 schrieb William F Pokorny:
> On 08/24/2016 10:06 PM, clipka wrote:
>> FYI, I've just put UberPOV back on the tracks.
>>
>> The current development version includes all the latest and greatest
>> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
>> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>>
>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>>
> Good news.
> 
> Am I correct pull requests for potential features would be issued
> against the UberPov develop branch?

That depends.

If the feature fits snugly into POV-Ray proper right away, I'd prefer to
pull it directly into the official branch.

But for features that may need testing "in the wild", I guess UberPOV
would make for a nice testbed and proving ground; after all that was
intended to be one of its main purposes.

> Are new features following the "POV-Ray Patch Identification Proposal"
> you proposed back in 2013?

Yes, I intend to continue that concept.

> I've two initial patches in mind. Namely the new density_file
> interpolations and the tweak to the blob internal variable. In my
> testing earlier this year against many old problem cases(1) the latter
> blob fix looked good to me.

As a matter of fact your density_file patch is the primary reason why
I've revisited UberPOV right now.

As for the "blob internal variable", that doesn't ring a bell in me at
present, but I suspect there's something interesting behind it as well.

Speaking of density files -- since you've been dealing with those
recently, how would you feel about implementing a 3-channel RGB variant?
Something akin to `image_map` but in 3D? I have a hunch that some people
might like to have such a thing, but I currently don't find the time myself.

[Mr] Re: read pov scene text from RAM instead of disk... [3517 days 2 hours and 58 minutes ago]

Fri, 26 Aug 2016 13:10:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> >
> > Unfortunately that approach probably only works for a console version,
> > not the current Windows binaries. Reading from the standard input stream
> > in Windows GUI programs seems to be non-trivial.
>
> console version - very good idea.
> Me and Mr. needed powerful tool for rendering.
> Windows GUI pulls back.
>
> :))))))

Indeed, that's rather a cheap price to pay (I no longer install povwin at every
updates since it's possible... load pov text files on notepad++ ) and one day
even blender text editor would be just as well when it will allow custom syntax
highlight.

Having this kind of speedup sounds really cool !

[William F Pokorny] Re: UberPOV is back [3517 days 4 hours and 22 minutes ago]

Fri, 26 Aug 2016 11:45:22 GMT

On 08/24/2016 10:06 PM, clipka wrote:
> FYI, I've just put UberPOV back on the tracks.
>
> The current development version includes all the latest and greatest
> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>
Good news.

Am I correct pull requests for potential features would be issued 
against the UberPov develop branch?

Are new features following the "POV-Ray Patch Identification Proposal" 
you proposed back in 2013?

I've two initial patches in mind. Namely the new density_file 
interpolations and the tweak to the blob internal variable. In my 
testing earlier this year against many old problem cases(1) the latter 
blob fix looked good to me.

Bill P.

(1) - I've still to organize and package those test cases ahead of 
opening a github issue.

[Thomas de Groot] Re: UberPOV is back [3518 days 9 hours and 34 minutes ago]

Thu, 25 Aug 2016 06:33:37 GMT

On 25-8-2016 4:06, clipka wrote:
> FYI, I've just put UberPOV back on the tracks.
>
> The current development version includes all the latest and greatest
> from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
> (Oren-Nayar and Lommel-Seeliger), and can be found here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754
>

Thank you! Thank you, Master!

-- 
Thomas

[clipka] UberPOV is back [3518 days 14 hours and 2 minutes ago]

Thu, 25 Aug 2016 02:06:08 GMT

FYI, I've just put UberPOV back on the tracks.

The current development version includes all the latest and greatest
from the POV-Ray 3.7.1 "master" branch, plus the advanced diffuse models
(Oren-Nayar and Lommel-Seeliger), and can be found here:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.1-alpha.8756754

[LanuHum] Re: read pov scene text from RAM instead of disk... [3519 days 2 hours and 18 minutes ago]

Wed, 24 Aug 2016 13:50:01 GMT

clipka <ano### [at] anonymousorg> wrote:

>
> Unfortunately that approach probably only works for a console version,
> not the current Windows binaries. Reading from the standard input stream
> in Windows GUI programs seems to be non-trivial.

console version - very good idea.
Me and Mr. needed powerful tool for rendering.
Windows GUI pulls back.

:))))))

[clipka] Re: read pov scene text from RAM instead of disk... [3519 days 17 hours and 57 minutes ago]

Tue, 23 Aug 2016 22:10:21 GMT

Am 23.08.2016 um 22:11 schrieb LanuHum:
> "Mr" <nomail@nomail> wrote:
>> Hi!
>> Is there a way for official pov or any other branch/patched verion, to read a
>> pov scene from Python string in RAM...?
>>
>> (either directly or maybe using something like this?
>> http://docs.python.org/3/library/io.html#io.StringIO  )
>>
>> Instead of having to write and read from the text file to disk, it would
>> probably make my exporter much faster for small scenes.
> 
> It is not required. Required to render an external file instead ate
> one-dimensional array of string variables.
> char *povfile[] = {"#version", "3.7", "background","{","color"...and so on};
> 
> As the file can be written in one line, and the python can transmit the exact
> same string.
> Developers only need to specify how to count?
> From a file or from a file.
> Oh array in english is file? Your language does not even see the difference.
> :)))))))

No, array in English is not file. It is not the language that fails to
see the difference, but your translation software :P

> I see a simple desire

Hmm... I guess one way to approach this could be to allow the source
"file" to be read from the standard input stream.

Up to now that wasn't a realistic option, because you can't rewind the
standard input stream, and therefore neither loops nor macros would work.

However, now that I've implemented cached macros, which works by parsing
from a memory buffer rather than a file, it would be comparatively easy
to apply the same mechanism to cache an entire file -- or the standard
input stream, for that matter.

Unfortunately that approach probably only works for a console version,
not the current Windows binaries. Reading from the standard input stream
in Windows GUI programs seems to be non-trivial.

[LanuHum] Re: read pov scene text from RAM instead of disk... [3519 days 19 hours and 53 minutes ago]

Tue, 23 Aug 2016 20:15:01 GMT

"Mr" <nomail@nomail> wrote:
> Hi!
> Is there a way for official pov or any other branch/patched verion, to read a
> pov scene from Python string in RAM...?
>
> (either directly or maybe using something like this?
> http://docs.python.org/3/library/io.html#io.StringIO  )
>
> Instead of having to write and read from the text file to disk, it would
> probably make my exporter much faster for small scenes.

It is not required. Required to render an external file instead ate
one-dimensional array of string variables.
char *povfile[] = {"#version", "3.7", "background","{","color"...and so on};

As the file can be written in one line, and the python can transmit the exact
same string.
Developers only need to specify how to count?
From a file or from a file.
Oh array in english is file? Your language does not even see the difference.
:)))))))
I see a simple desire

[Mr] Re: read pov scene text from RAM instead of disk... [3520 days 8 hours and 38 minutes ago]

Tue, 23 Aug 2016 07:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 22.08.2016 um 13:33 schrieb Mr:
> > Hi!
> > Is there a way for official pov or any other branch/patched verion, to read a
> > pov scene from Python string in RAM...?
> >
> > (either directly or maybe using something like this?
> > http://docs.python.org/3/library/io.html#io.StringIO  )
>
> Nothing that could be used in conjunction with how you're presumably
> invoking POV-Ray.

Ok thanks, it looks like most of the time lost is the conversion between binary
to ascii data... and I don't have any compiled language skill to create/refresh
an exchange API in pov... current rendering speed will have to do with only a
little Python optimization when possible.

[clipka] Re: read pov scene text from RAM instead of disk... [3520 days 20 hours and 12 minutes ago]

Mon, 22 Aug 2016 19:55:48 GMT

Am 22.08.2016 um 13:33 schrieb Mr:
> Hi!
> Is there a way for official pov or any other branch/patched verion, to read a
> pov scene from Python string in RAM...?
> 
> (either directly or maybe using something like this?
> http://docs.python.org/3/library/io.html#io.StringIO  )

Nothing that could be used in conjunction with how you're presumably
invoking POV-Ray.

[Le Forgeron] Re: read pov scene text from RAM instead of disk... [3521 days 3 hours and 5 minutes ago]

Mon, 22 Aug 2016 13:02:48 GMT

Le 22/08/2016 Ã  13:33, Mr a Ã©crit :
> Hi!
> Is there a way for official pov or any other branch/patched verion, to read a
> pov scene from Python string in RAM...?
>
> (either directly or maybe using something like this?
> http://docs.python.org/3/library/io.html#io.StringIO  )
>
> Instead of having to write and read from the text file to disk, it would
> probably make my exporter much faster for small scenes.
>

If you are on linux, you could mount the directory where the file is 
exported as a ramdisk (before launching any of your tools and povray)

http://www.linuxscrew.com/2010/03/24/fastest-way-to-create-ramdisk-in-ubuntulinux/

> http://www.linuxscrew.com/2010/03/24/fastest-way-to-create-ramdisk-in-ubuntulinux/

It has to be on a filesystem for povray, but nothing says that the 
filesystem cannot be in RAM.

If you are not changing the default output directory, you should 
provision enough room for the intermediate files and output pictures.

[Mr] read pov scene text from RAM instead of disk file [3521 days 4 hours and 33 minutes ago]

Mon, 22 Aug 2016 11:35:00 GMT

Hi!
Is there a way for official pov or any other branch/patched verion, to read a
pov scene from Python string in RAM...?

(either directly or maybe using something like this?
http://docs.python.org/3/library/io.html#io.StringIO  )

Instead of having to write and read from the text file to disk, it would
probably make my exporter much faster for small scenes.

[Jaime Vives Piqueres] Re: mesh data extraction patch [3689 days 6 hours and 17 minutes ago]

Mon, 7 Mar 2016 09:50:34 GMT

El 07/03/16 a las 09:38, Jaime Vives Piqueres escribiÃ³:
> El 07/03/16 a las 09:20, Le_Forgeron escribiÃ³:
>> Did you put on configure line LIBS="-lboost_system -lboost_thread"
>> ?
>
> Ok, that worked... thanks!
>

   ...and my idea for covering the mesh surface works too (tough it needs
some work still). I think it will be useful to "furrify" mesh objects too.

--
jaime

[Jaime Vives Piqueres] Re: mesh data extraction patch [3689 days 7 hours and 30 minutes ago]

Mon, 7 Mar 2016 08:38:16 GMT

El 07/03/16 a las 09:20, Le_Forgeron escribiÃ³:
> Did you put on configure line LIBS="-lboost_system -lboost_thread" ?

   Ok, that worked... thanks!

--
jaime

[Jaime Vives Piqueres] Re: mesh data extraction patch [3689 days 7 hours and 40 minutes ago]

Mon, 7 Mar 2016 08:27:56 GMT

El 07/03/16 a las 09:20, Le_Forgeron escribiÃ³:
> Did you put on configure line LIBS="-lboost_system -lboost_thread" ?

   No... I used to need that configure option with the first iterations
of 3.7 on Ubuntu 12.04, but at some point it wasn't need anymore.


> What is the version of boost on ubuntu 14.04 ?


1.54.0

--
jaime

[Le Forgeron] Re: mesh data extraction patch [3689 days 7 hours and 48 minutes ago]

Mon, 7 Mar 2016 08:20:17 GMT

Le 06/03/2016 23:31, clipka a Ã©crit :
> Am 06.03.2016 um 21:16 schrieb Jaime Vives Piqueres:
>> El 06/03/16 a las 11:20, Le_Forgeron escribiÃ³:
>>> It was done in megapov, and it's currently also in hg-povray.
>>
>>    Cannot compile hg-povray... I get a bunch of boost errors (undefined
>> references): are the libraries requirements different from povray
>> master? I'm on Ubuntu 14.04, and can compile povray master and uberpov
>> without problems.
>
> Boost 1.50 broke some stuff, and support has only been added quite a
> while after the official 3.7.0 release; hg-povray might still be based
> on a version of POV-Ray that didn't support boost 1.50 or later.
>

Did you put on configure line LIBS="-lboost_system -lboost_thread" ?

What is the version of boost on ubuntu 14.04 ?

[clipka] Re: mesh data extraction patch [3689 days 17 hours and 37 minutes ago]

Sun, 6 Mar 2016 22:31:11 GMT

Am 06.03.2016 um 21:16 schrieb Jaime Vives Piqueres:
> El 06/03/16 a las 11:20, Le_Forgeron escribiÃ³:
>> It was done in megapov, and it's currently also in hg-povray.
> 
>   Cannot compile hg-povray... I get a bunch of boost errors (undefined
> references): are the libraries requirements different from povray
> master? I'm on Ubuntu 14.04, and can compile povray master and uberpov
> without problems.

Boost 1.50 broke some stuff, and support has only been added quite a
while after the official 3.7.0 release; hg-povray might still be based
on a version of POV-Ray that didn't support boost 1.50 or later.

[Jaime Vives Piqueres] Re: mesh data extraction patch [3689 days 19 hours and 51 minutes ago]

Sun, 6 Mar 2016 20:16:39 GMT

El 06/03/16 a las 11:20, Le_Forgeron escribiÃ³:
> It was done in megapov, and it's currently also in hg-povray.

   Cannot compile hg-povray... I get a bunch of boost errors (undefined
references): are the libraries requirements different from povray
master? I'm on Ubuntu 14.04, and can compile povray master and uberpov
without problems.

--
jaime

[Jaime Vives Piqueres] Re: mesh data extraction patch [3690 days 5 hours and 32 minutes ago]

Sun, 6 Mar 2016 10:35:19 GMT

El 06/03/16 a las 11:20, Le_Forgeron escribiÃ³:
> It was done in megapov,

   Megapov was amazing... and underused, I see, at least on my side. I
don't know how I missed that feature back then.

> and it's currently also in hg-povray.

   Thats great! I will try it... should have some real-world uses for it,
apart from "rockyfying" my cave.

--
jaime

[Le Forgeron] Re: mesh data extraction patch [3690 days 5 hours and 47 minutes ago]

Sun, 6 Mar 2016 10:20:47 GMT

Le 06/03/2016 10:56, Jaime Vives Piqueres a Ã©crit :
> During my current cave experiments, I thought it would be useful to have
> access to mesh data, to more effectively place things on the mesh
> surface. Using trace() against the mesh works, but it's not very
> efficient when the mesh geometry is somewhat complex.
> 
> So I searched to see if someone ever made a patch to access mesh data,
> in a way that could allow to loop over the triangles, and found that
> Warp had a tentative patch for this:
> 
>
http://news.povray.org/povray.unofficial.patches/thread/%3CXns900D79CAEseed7%40povray.org%3E/
> 
> I don't know if he ever actually created such a patch or was only
> exposing the idea, but I think something exactly like that would be
> terrifically useful.
> 
> So, my question is, would it be too hard to implement?

It was done in megapov, and it's currently also in hg-povray.

http://wiki.povray.org/content/User:Le_Forgeron

[Jaime Vives Piqueres] mesh data extraction patch [3690 days 6 hours and 12 minutes ago]

Sun, 6 Mar 2016 09:56:08 GMT

During my current cave experiments, I thought it would be useful to have
access to mesh data, to more effectively place things on the mesh
surface. Using trace() against the mesh works, but it's not very
efficient when the mesh geometry is somewhat complex.

So I searched to see if someone ever made a patch to access mesh data,
in a way that could allow to loop over the triangles, and found that
Warp had a tentative patch for this:

http://news.povray.org/povray.unofficial.patches/thread/%3CXns900D79CAEseed7%40povray.org%3E/

I don't know if he ever actually created such a patch or was only
exposing the idea, but I think something exactly like that would be
terrifically useful.

So, my question is, would it be too hard to implement?


P.S.: Yes, Clipka, that's a covert feature request... ;)

--
jaime

[StephenS] Re: UberPOV v1.37.1.0-beta.10 released [4045 days 17 hours and 18 minutes ago]

Mon, 16 Mar 2015 22:50:00 GMT

....
> Can you please send the .pov file
....
I think I've sent it.

Stephen S

[clipka] Re: UberPOV v1.37.1.0-beta.10 released [4046 days 11 hours and 25 minutes ago]

Mon, 16 Mar 2015 04:42:55 GMT

Am 16.03.2015 um 02:02 schrieb StephenS:

> I have a scene that fails to run on
> UberPOV 1.37.1.0-beta.10.msvc10.win64
> but will run on POV 3.7.0

How about the latest POV-Ray 3.7.1 development release? 
(https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.7930357)

> After several tries it's produced a minidump, interested?

Unfortunately I wouldn't know what to do with a dump, actually. I'd 
rather try to replicate the issue here.

> It may be awhile before I have time to trim the file down.
> Basic_stage_11564_.pov 353kb
> I see #include "lightsys.inc" also.

Can you please send the .pov file to Christoph, at Lipka minus Koeln, 
DEutschland? I'll try to trim it down myself.

Don't bother to send the lightsys stuff, as I have it here already. 
Please do include other non-standard inc files though.

[StephenS] Re: UberPOV v1.37.1.0-beta.10 released [4046 days 15 hours and 3 minutes ago]

Mon, 16 Mar 2015 01:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> For all the Windows jockeys out there, here's a beta release of the
> latest bugfixes:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.10

I have a scene that fails to run on
UberPOV 1.37.1.0-beta.10.msvc10.win64
but will run on POV 3.7.0

After several tries it's produced a minidump, interested?

It may be awhile before I have time to trim the file down.
Basic_stage_11564_.pov 353kb
I see #include "lightsys.inc" also.

Stephen S

[James Holsenback] Re: experimental features reporting [4060 days 18 hours and 42 minutes ago]

Sun, 1 Mar 2015 21:25:42 GMT

On 02/28/2015 07:55 PM, clipka wrote:
> Am 27.02.2015 um 15:45 schrieb James Holsenback:
>> On 02/27/2015 01:31 AM, clipka wrote:
>>> Am 26.02.2015 um 18:43 schrieb James Holsenback:
>>>> Just noticed an anomaly with the Parse Warning message when subsurface
>>>> is used ...
>>>
>>> Did you already check whether this is an UberPOV-specific issue or
>>> whether it also appears in latest POV-Ray proper?
>>>
>>
>> POV-Ray 3.7.1-alpha.7898287.unofficial is ok
>
> alpha.7965778 isn't ;)
>
> Next time I mess with some C/C++ language feature I have no ken of (in
> this case variadic arguments), someone please kick me.
>

ok ... the word was almost enough of a clue but i had to ask the great 
oracle what the heck you were talking about. the example i found looks 
like a chase your own tail type of situation ... have fun!!!

[clipka] Re: experimental features reporting [4061 days 15 hours and 12 minutes ago]

Sun, 1 Mar 2015 00:55:47 GMT

Am 27.02.2015 um 15:45 schrieb James Holsenback:
> On 02/27/2015 01:31 AM, clipka wrote:
>> Am 26.02.2015 um 18:43 schrieb James Holsenback:
>>> Just noticed an anomaly with the Parse Warning message when subsurface
>>> is used ...
>>
>> Did you already check whether this is an UberPOV-specific issue or
>> whether it also appears in latest POV-Ray proper?
>>
>
> POV-Ray 3.7.1-alpha.7898287.unofficial is ok

alpha.7965778 isn't ;)

Next time I mess with some C/C++ language feature I have no ken of (in 
this case variadic arguments), someone please kick me.

[James Holsenback] Re: experimental features reporting [4063 days 1 hour and 23 minutes ago]

Fri, 27 Feb 2015 14:45:14 GMT

On 02/27/2015 01:31 AM, clipka wrote:
> Am 26.02.2015 um 18:43 schrieb James Holsenback:
>> Just noticed an anomaly with the Parse Warning message when subsurface
>> is used ...
>
> Did you already check whether this is an UberPOV-specific issue or
> whether it also appears in latest POV-Ray proper?
>

POV-Ray 3.7.1-alpha.7898287.unofficial is ok

[clipka] Re: experimental features reporting [4063 days 9 hours and 37 minutes ago]

Fri, 27 Feb 2015 06:31:14 GMT

Am 26.02.2015 um 18:43 schrieb James Holsenback:
> Just noticed an anomaly with the Parse Warning message when subsurface
> is used ...

Did you already check whether this is an UberPOV-specific issue or 
whether it also appears in latest POV-Ray proper?

[James Holsenback] experimental features reporting [4063 days 22 hours and 24 minutes ago]

Thu, 26 Feb 2015 17:44:06 GMT

Just noticed an anomaly with the Parse Warning message when subsurface 
is used ...

[clipka] Re: uberpov beta9b throws assertion [4080 days 7 hours and 7 minutes ago]

Tue, 10 Feb 2015 09:00:38 GMT

Am 05.02.2015 um 06:04 schrieb James Holsenback:
> uberpov: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
> boost::shared_ptr<T>::operator->() const [with T = pov::BasicPattern]:
> Assertion `px != 0' failed.
> /home/ash/scripts/render: line 2:  8705 Aborted                 uberpov
> Work Options[Some] Options[M16BY9] Options[Pause]
>
> Interesting that it refers to my render script because it happened when
> I got over zealous with commenting out something in a material definition:
>
> #declare Band_=
> material {
>      texture {  // uv_mapping
>          //granite  <--- fat fingers
>          poly_wave 2
>          lambda 6
>          turbulence 0.1
>          scale 4
>          warp { toroidal }
>          texture_map {
>              [0.0 Band2]
>              [0.1250/5 Band1]
>              [0.1250/5 Band1]
>              [0.5 Band2]
>              [0.5 Band1]
>              [1.0 Band1]
>              }
>          }
>      interior { ior 1.5 }
>      }

This is actually not an UberPOV-specific issue at all; it's carried over 
from official POV-Ray.

[Thomas de Groot] Re: UberPOV v1.37.1.0-beta.10 released [4080 days 7 hours and 45 minutes ago]

Tue, 10 Feb 2015 08:23:15 GMT

On 9-2-2015 19:48, clipka wrote:
> For all the Windows jockeys out there, here's a beta release of the
> latest bugfixes:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.10
Thanks indeed!

-- 
Thomas

[James Holsenback] Re: UberPOV v1.37.1.0-beta.10 released [4080 days 19 hours and 10 minutes ago]

Mon, 9 Feb 2015 20:57:33 GMT

On 02/09/2015 01:48 PM, clipka wrote:
> For all the Windows jockeys out there, here's a beta release of the
> latest bugfixes:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.10

pulled the beta10 source and it builds fine on my linux platform ... i 
DO appreciate your devotion to the project

[clipka] UberPOV v1.37.1.0-beta.10 released [4080 days 21 hours and 19 minutes ago]

Mon, 9 Feb 2015 18:48:56 GMT

For all the Windows jockeys out there, here's a beta release of the 
latest bugfixes:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.10

[clipka] Re: uberpov beta9b throws assertion [4085 days 8 hours and 50 minutes ago]

Thu, 5 Feb 2015 07:18:09 GMT

Am 05.02.2015 um 06:04 schrieb James Holsenback:
> uberpov: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T*
> boost::shared_ptr<T>::operator->() const [with T = pov::BasicPattern]:
> Assertion `px != 0' failed.
> /home/ash/scripts/render: line 2:  8705 Aborted                 uberpov
> Work Options[Some] Options[M16BY9] Options[Pause]
>
> Interesting that it refers to my render script because it happened when
> I got over zealous with commenting out something in a material definition:

technically it's not refering to your render script, but to internal 
data types ;)

> #declare Band_=
> material {
>      texture {  // uv_mapping
>          //granite  <--- fat fingers
>          poly_wave 2
>          lambda 6
>          turbulence 0.1

I guess the parser doesn't like these in plain patterns for rather 
obvious reasons. But it shouldn't crash, that's for sure. I'll need to 
have a look at it.

[James Holsenback] uberpov beta9b throws assertion [4085 days 11 hours and 4 minutes ago]

Thu, 5 Feb 2015 05:04:03 GMT

uberpov: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* 
boost::shared_ptr<T>::operator->() const [with T = pov::BasicPattern]: 
Assertion `px != 0' failed.
/home/ash/scripts/render: line 2:  8705 Aborted                 uberpov 
Work Options[Some] Options[M16BY9] Options[Pause]

Interesting that it refers to my render script because it happened when 
I got over zealous with commenting out something in a material definition:

#declare Band_=
material {
	texture {  // uv_mapping
		//granite  <--- fat fingers
		poly_wave 2
		lambda 6
		turbulence 0.1
		scale 4
		warp { toroidal }
		texture_map {
			[0.0 Band2]
			[0.1250/5 Band1]
			[0.1250/5 Band1]
			[0.5 Band2]
			[0.5 Band1]
			[1.0 Band1]
			}
		}
	interior { ior 1.5 }
	}

[Doctor John] Re: boost max_trace_level? [4088 days 7 hours and 35 minutes ago]

Mon, 2 Feb 2015 08:33:03 GMT

On 01/02/15 19:08, John wrote:
> Works great, thanks. If I need more, I hope you'll be willing to make another
> version. It's possible to run really huge refractive simulations on Lonestar,
> which has POV-Ray:
> 
> https://www.tacc.utexas.edu/systems/lonestar
> 
> 

Gimme, gimme, gimme!

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

[John] Re: boost max_trace_level? [4088 days 20 hours and 58 minutes ago]

Sun, 1 Feb 2015 19:10:00 GMT

Works great, thanks. If I need more, I hope you'll be willing to make another
version. It's possible to run really huge refractive simulations on Lonestar,
which has POV-Ray:

https://www.tacc.utexas.edu/systems/lonestar

[John] Re: boost max_trace_level? [4089 days and 8 minutes ago]

Sun, 1 Feb 2015 16:00:00 GMT

Thanks! I will try it out this afternoon.  The reason I used the old version is
a combination of laziness and fear of upgrades.

1024 will help a lot.

-John

[Doctor John] Re: UberPOV v1.37.1.0-beta.9 released [4089 days and 38 minutes ago]

Sun, 1 Feb 2015 15:29:32 GMT

On 01/02/15 14:15, Doctor John wrote:
> 
> I got the same error as James but I was compiling on a 64 bit machine.
> After removal of offending word, all is sweetness and light
> 
> John
> 

Additional:
john@linux-bh1u:~> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-4.8 --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

[Doctor John] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 1 hour and 52 minutes ago]

Sun, 1 Feb 2015 14:15:37 GMT

On 01/02/15 06:38, clipka wrote:
> Am 01.02.2015 um 07:23 schrieb James Holsenback:
> 
>> yer gettin' closer:
>>
>> backend/povray.cpp: In function â€˜void
>> {anonymous}::BuildInitInfo(POVMSObjectPtr)â€™:
>> backend/povray.cpp:301:115: error: expected â€˜)â€™
before â€˜SSE2_INCLUDEDâ€™
> 
> Strangely enough, I didn't come across that one on my Linux machine.
> Are you building on a 32 bit computer?
> 
> Until I figure this one out, I recommend you just remove the
> "SSE2_INCLUDED" from that line (any anywhere else where it might cause
> hiccups).
> 

It appears that removing SSE_INCLUDED from line 301 in
backend/povray.cpp does the trick.

I got the same error as James but I was compiling on a 64 bit machine.
After removal of offending word, all is sweetness and light

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

[Yvo Smellenbergh] Re: boost max_trace_level? [4089 days 5 hours and 57 minutes ago]

Sun, 1 Feb 2015 10:10:24 GMT

On 2015-01-31 17:01:54 +0000, John said:

> I am using Yvo's 3.7.0 RC6 unofficial (Universal 64 bit, Dec 14 2012) 
> in OS X to
That is a very old version, please download the most recent version at:
http://megapov.inetart.net/povrayunofficial_mac/

> research turbulence models in the atmosphere, using clipka's focal_blur camera
> that allows you to specify the number of test rays.
> 
> However, I've bumped into the max_trace_level limit of 256.
> 
> Any chance of making a special edition for OS X/Yosemite that boosts 
> this limit?
To what value? Here is a version with a limit of 1024:
http://megapov.inetart.net/beta/POVRay3_7_Unofficial_trace_1024.zip

Yvo


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


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 9 hours and 21 minutes ago]

Sun, 1 Feb 2015 06:46:53 GMT

On 02/01/2015 01:38 AM, clipka wrote:
> Am 01.02.2015 um 07:23 schrieb James Holsenback:
>
>> yer gettin' closer:
>>
>> backend/povray.cpp: In function â€˜void
>> {anonymous}::BuildInitInfo(POVMSObjectPtr)â€™:
>> backend/povray.cpp:301:115: error: expected â€˜)â€™
before â€˜SSE2_INCLUDEDâ€™
>
> Strangely enough, I didn't come across that one on my Linux machine.
> Are you building on a 32 bit computer?

yes

>
> Until I figure this one out, I recommend you just remove the
> "SSE2_INCLUDED" from that line (any anywhere else where it might cause
> hiccups).
>

was already in the file trying to make repair when i saw your reply ... 
line 301 was the only place

[clipka] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 9 hours and 29 minutes ago]

Sun, 1 Feb 2015 06:39:00 GMT

Am 01.02.2015 um 07:23 schrieb James Holsenback:

> yer gettin' closer:
>
> backend/povray.cpp: In function â€˜void
> {anonymous}::BuildInitInfo(POVMSObjectPtr)â€™:
> backend/povray.cpp:301:115: error: expected â€˜)â€™
before â€˜SSE2_INCLUDEDâ€™

Strangely enough, I didn't come across that one on my Linux machine.
Are you building on a 32 bit computer?

Until I figure this one out, I recommend you just remove the 
"SSE2_INCLUDED" from that line (any anywhere else where it might cause 
hiccups).

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 9 hours and 44 minutes ago]

Sun, 1 Feb 2015 06:23:58 GMT

On 02/01/2015 12:56 AM, clipka wrote:
> Am 31.01.2015 um 09:47 schrieb clipka:
>> Latest UberPOV version, with all the new official POV-Ray bells &
>> whistles merged in.
>>
>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9
>
> As Jim has pointed out, beta.9 doesn't compile on Linux, so here's a
> source code update:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9b
>

yer gettin' closer:

backend/povray.cpp: In function â€˜void 
{anonymous}::BuildInitInfo(POVMSObjectPtr)â€™:
backend/povray.cpp:301:115: error: expected â€˜)â€™
before â€˜SSE2_INCLUDEDâ€™

[clipka] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 10 hours and 11 minutes ago]

Sun, 1 Feb 2015 05:56:53 GMT

Am 31.01.2015 um 09:47 schrieb clipka:
> Latest UberPOV version, with all the new official POV-Ray bells &
> whistles merged in.
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9

As Jim has pointed out, beta.9 doesn't compile on Linux, so here's a 
source code update:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9b

[clipka] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 10 hours and 53 minutes ago]

Sun, 1 Feb 2015 05:14:27 GMT

Am 01.02.2015 um 05:08 schrieb James Holsenback:
> On 01/31/2015 10:37 PM, clipka wrote:
>> Am 01.02.2015 um 02:26 schrieb James Holsenback:
>>
>>> Same error that I'm getting with ANY source AFTER beta6 (which built
>>> just fine)
>>
>> Can you please do me a favor and check again with the following versions:
>>
>>      ce0aae6b54d434ceb3daf7410582f95ea742ac14 (2014-07-27)
>>      e1028cd0dbb0918324cf9b898906b54222fc67da (2014-07-29)
>>
>> I have strong reason to believe that the latter introduced the error.
>> Which also means that it's probably already present in the
>> feature/colour_model branch in the official POV-Ray repo.
>>
>
> ce0aae6b54d434ceb3daf7410582f95ea742ac14 has the same error so I did NOT
> pull e1028cd0dbb0918324cf9b898906b54222fc67da

Strange - I suspect you must have done something wrong there. Never 
mind, I've been able to reproduce the error and trace it back to the 
"feature/colour_model" branch in the official repo (which is what 
UberPOV is based on). I'm currently in the process of releasing a fix.

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 12 hours ago]

Sun, 1 Feb 2015 04:08:01 GMT

On 01/31/2015 10:37 PM, clipka wrote:
> Am 01.02.2015 um 02:26 schrieb James Holsenback:
>
>> Same error that I'm getting with ANY source AFTER beta6 (which built
>> just fine)
>
> Can you please do me a favor and check again with the following versions:
>
>      ce0aae6b54d434ceb3daf7410582f95ea742ac14 (2014-07-27)
>      e1028cd0dbb0918324cf9b898906b54222fc67da (2014-07-29)
>
> I have strong reason to believe that the latter introduced the error.
> Which also means that it's probably already present in the
> feature/colour_model branch in the official POV-Ray repo.
>

ce0aae6b54d434ceb3daf7410582f95ea742ac14 has the same error so I did NOT 
pull e1028cd0dbb0918324cf9b898906b54222fc67da

[clipka] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 12 hours and 30 minutes ago]

Sun, 1 Feb 2015 03:37:39 GMT

Am 01.02.2015 um 02:26 schrieb James Holsenback:

> Same error that I'm getting with ANY source AFTER beta6 (which built
> just fine)

Can you please do me a favor and check again with the following versions:

     ce0aae6b54d434ceb3daf7410582f95ea742ac14 (2014-07-27)
     e1028cd0dbb0918324cf9b898906b54222fc67da (2014-07-29)

I have strong reason to believe that the latter introduced the error. 
Which also means that it's probably already present in the 
feature/colour_model branch in the official POV-Ray repo.

[clipka] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 12 hours and 57 minutes ago]

Sun, 1 Feb 2015 03:10:57 GMT

Am 01.02.2015 um 02:49 schrieb James Holsenback:

>> and noticed the checking whether g++ accepts yada-yada shows up for the
>> beta9 configure ... is that a clue?
>
> Oh ... and the Compiler flags shows -Wno-non-template-friend for b9 as well

Nope (presuming with "yada-yada" you mean "-Wno-non-template-friend"); 
this is just the suppression of an unwarranted warning from g++. 
Effectively, what this is all about is that there was a quirk in older 
g++ versions violating the C++ specs, and now by default they issue a 
warning just in case your code was relying on g++'s old behaviour.

I'll have a closer look at it. It's certainly not something affecting 
the Windows build.

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 14 hours and 17 minutes ago]

Sun, 1 Feb 2015 01:50:38 GMT

On 01/31/2015 08:49 PM, James Holsenback wrote:
> On 01/31/2015 08:46 PM, James Holsenback wrote:
>> On 01/31/2015 08:26 PM, James Holsenback wrote:
>>> On 01/31/2015 03:47 AM, clipka wrote:
>>>> Latest UberPOV version, with all the new official POV-Ray bells &
>>>> whistles merged in.
>>>>
>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9
>>>
>>> I'm getting this error during the make portion of the build:
>>>
>>> In file included from backend/frame.h:67:0,
>>>                   from lightgrp.cpp:35:
>>> ./base/colour.h: In member function
>>> â€˜pov_base::GenericTrans<COLOUR_T>::Channel
>>> pov_base::GenericTrans<COLOUR_T>::LegacyOpacity(const Colour&)
constâ€™:
>>> ./base/colour.h:1132:28: error: â€˜colâ€™ was not
declared in this scope
>>> In file included from backend/frame.h:67:0,
>>>                   from lightgrp.cpp:35:
>>> ./base/colour.h: In constructor
>>> â€˜pov_base::GenericTransColour<CT>::GenericTransColour(const
Colour&,
>>> pov_base::GenericTransColour<CT>::Channel,
>>> pov_base::GenericTransColour<CT>::Channel)â€™:
>>> ./base/colour.h:1933:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™
>>> does not have any field named â€˜mFilterâ€™
>>> ./base/colour.h:1934:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™
>>> does not have any field named â€˜mTransmâ€™
>>> make[2]: *** [lightgrp.o] Error 1
>>> make[2]: Leaving directory
>>> `/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9/source'
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory
>>> `/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9'
>>> make: *** [all] Error 2
>>>
>>> Same error that I'm getting with ANY source AFTER beta6 (which built
>>> just fine)
>>
>> thinking it's the configure phase I redirected output to file to compare
>> results:
>>
>> diff c-outb6 c-outb9
>> 4c4
>> < Configure UberPOV version 1.37.0.0-beta.6
>> ---
>>  > Configure UberPOV version 1.37.1.0-beta.9
>> 177a178
>>  > checking whether g++ accepts -Wno-non-template-friend... yes
>> 222c223
>> < UberPOV 1.37.0.0-beta.6 has been configured.
>> ---
>>  > UberPOV 1.37.1.0-beta.9 has been configured.
>> 235c236
>> <   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
>> -fno-enforce-eh-specs -s -O3 -ffast-math -malign-double
>>   -march=native -pthread
>> ---
>>  >   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
>> -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -
>> ffast-math -malign-double -march=native -pthread
>>
>> and noticed the checking whether g++ accepts yada-yada shows up for the
>> beta9 configure ... is that a clue?
>
> Oh ... and the Compiler flags shows -Wno-non-template-friend for b9 as well

holy crap i'm rusty (bare with me) haven't even TOUCHED pov/uber for 
almost 3 months now: I'm using gcc (SUSE Linux) 4.6.2

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 14 hours and 19 minutes ago]

Sun, 1 Feb 2015 01:49:01 GMT

On 01/31/2015 08:46 PM, James Holsenback wrote:
> On 01/31/2015 08:26 PM, James Holsenback wrote:
>> On 01/31/2015 03:47 AM, clipka wrote:
>>> Latest UberPOV version, with all the new official POV-Ray bells &
>>> whistles merged in.
>>>
>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9
>>
>> I'm getting this error during the make portion of the build:
>>
>> In file included from backend/frame.h:67:0,
>>                   from lightgrp.cpp:35:
>> ./base/colour.h: In member function
>> â€˜pov_base::GenericTrans<COLOUR_T>::Channel
>> pov_base::GenericTrans<COLOUR_T>::LegacyOpacity(const Colour&)
constâ€™:
>> ./base/colour.h:1132:28: error: â€˜colâ€™ was not
declared in this scope
>> In file included from backend/frame.h:67:0,
>>                   from lightgrp.cpp:35:
>> ./base/colour.h: In constructor
>> â€˜pov_base::GenericTransColour<CT>::GenericTransColour(const
Colour&,
>> pov_base::GenericTransColour<CT>::Channel,
>> pov_base::GenericTransColour<CT>::Channel)â€™:
>> ./base/colour.h:1933:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™
>> does not have any field named â€˜mFilterâ€™
>> ./base/colour.h:1934:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™
>> does not have any field named â€˜mTransmâ€™
>> make[2]: *** [lightgrp.o] Error 1
>> make[2]: Leaving directory
>> `/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9/source'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory
>> `/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9'
>> make: *** [all] Error 2
>>
>> Same error that I'm getting with ANY source AFTER beta6 (which built
>> just fine)
>
> thinking it's the configure phase I redirected output to file to compare
> results:
>
> diff c-outb6 c-outb9
> 4c4
> < Configure UberPOV version 1.37.0.0-beta.6
> ---
>  > Configure UberPOV version 1.37.1.0-beta.9
> 177a178
>  > checking whether g++ accepts -Wno-non-template-friend... yes
> 222c223
> < UberPOV 1.37.0.0-beta.6 has been configured.
> ---
>  > UberPOV 1.37.1.0-beta.9 has been configured.
> 235c236
> <   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
> -fno-enforce-eh-specs -s -O3 -ffast-math -malign-double
>   -march=native -pthread
> ---
>  >   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
> -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -
> ffast-math -malign-double -march=native -pthread
>
> and noticed the checking whether g++ accepts yada-yada shows up for the
> beta9 configure ... is that a clue?

Oh ... and the Compiler flags shows -Wno-non-template-friend for b9 as well

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 14 hours and 21 minutes ago]

Sun, 1 Feb 2015 01:46:55 GMT

On 01/31/2015 08:26 PM, James Holsenback wrote:
> On 01/31/2015 03:47 AM, clipka wrote:
>> Latest UberPOV version, with all the new official POV-Ray bells &
>> whistles merged in.
>>
>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9
>
> I'm getting this error during the make portion of the build:
>
> In file included from backend/frame.h:67:0,
>                   from lightgrp.cpp:35:
> ./base/colour.h: In member function
> â€˜pov_base::GenericTrans<COLOUR_T>::Channel
> pov_base::GenericTrans<COLOUR_T>::LegacyOpacity(const Colour&)
constâ€™:
> ./base/colour.h:1132:28: error: â€˜colâ€™ was not
declared in this scope
> In file included from backend/frame.h:67:0,
>                   from lightgrp.cpp:35:
> ./base/colour.h: In constructor
> â€˜pov_base::GenericTransColour<CT>::GenericTransColour(const
Colour&,
> pov_base::GenericTransColour<CT>::Channel,
> pov_base::GenericTransColour<CT>::Channel)â€™:
> ./base/colour.h:1933:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™
> does not have any field named â€˜mFilterâ€™
> ./base/colour.h:1934:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™
> does not have any field named â€˜mTransmâ€™
> make[2]: *** [lightgrp.o] Error 1
> make[2]: Leaving directory
> `/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9/source'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9'
> make: *** [all] Error 2
>
> Same error that I'm getting with ANY source AFTER beta6 (which built
> just fine)

thinking it's the configure phase I redirected output to file to compare 
results:

diff c-outb6 c-outb9
4c4
< Configure UberPOV version 1.37.0.0-beta.6
---
 > Configure UberPOV version 1.37.1.0-beta.9
177a178
 > checking whether g++ accepts -Wno-non-template-friend... yes
222c223
< UberPOV 1.37.0.0-beta.6 has been configured.
---
 > UberPOV 1.37.1.0-beta.9 has been configured.
235c236
<   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -s -O3 -ffast-math -malign-double
  -march=native -pthread
---
 >   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -
ffast-math -malign-double -march=native -pthread

and noticed the checking whether g++ accepts yada-yada shows up for the 
beta9 configure ... is that a clue?

[James Holsenback] Re: UberPOV v1.37.1.0-beta.9 released [4089 days 14 hours and 41 minutes ago]

Sun, 1 Feb 2015 01:26:58 GMT

On 01/31/2015 03:47 AM, clipka wrote:
> Latest UberPOV version, with all the new official POV-Ray bells &
> whistles merged in.
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9

I'm getting this error during the make portion of the build:

In file included from backend/frame.h:67:0,
                  from lightgrp.cpp:35:
./base/colour.h: In member function 
â€˜pov_base::GenericTrans<COLOUR_T>::Channel 
pov_base::GenericTrans<COLOUR_T>::LegacyOpacity(const Colour&)
constâ€™:
./base/colour.h:1132:28: error: â€˜colâ€™ was not
declared in this scope
In file included from backend/frame.h:67:0,
                  from lightgrp.cpp:35:
./base/colour.h: In constructor 
â€˜pov_base::GenericTransColour<CT>::GenericTransColour(const Colour&, 
pov_base::GenericTransColour<CT>::Channel, 
pov_base::GenericTransColour<CT>::Channel)â€™:
./base/colour.h:1933:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™ 
does not have any field named â€˜mFilterâ€™
./base/colour.h:1934:13: error: class
â€˜pov_base::GenericTransColour<CT>â€™ 
does not have any field named â€˜mTransmâ€™
make[2]: *** [lightgrp.o] Error 1
make[2]: Leaving directory 
`/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9/source'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/ash/ScratchPad/uber/UberPOV-1.37.1.0-beta.9'
make: *** [all] Error 2

Same error that I'm getting with ANY source AFTER beta6 (which built 
just fine)

[clipka] Re: boost max_trace_level? [4089 days 15 hours and 40 minutes ago]

Sun, 1 Feb 2015 00:28:10 GMT

Am 31.01.2015 um 23:01 schrieb John:
> I am using Yvo's 3.7.0 RC6 unofficial (Universal 64 bit, Dec 14 2012) in OS X to
> research turbulence models in the atmosphere, using clipka's focal_blur camera
> that allows you to specify the number of test rays.
>
> However, I've bumped into the max_trace_level limit of 256.
>
> Any chance of making a special edition for OS X/Yosemite that boosts this limit?

That would certainly be a job for Yvo himself.

Building such a version should be a piece of cake (for someone familiar 
with building for OS X); from what I see, it should suffice to build 
with the preprocessor macro MAX_TRACE_LEVEL_LIMIT predefined to 
something larger than 256.

There might however be other limitations lurking in the shadows; they 
probably won't kick in right at max_trace_level 257, but don't expect 
max_trace_level 1000000000 to work flawlessly ;-)

[John] boost max_trace_level? [4089 days 18 hours and 3 minutes ago]

Sat, 31 Jan 2015 22:05:01 GMT

I am using Yvo's 3.7.0 RC6 unofficial (Universal 64 bit, Dec 14 2012) in OS X to
research turbulence models in the atmosphere, using clipka's focal_blur camera
that allows you to specify the number of test rays.

However, I've bumped into the max_trace_level limit of 256.

Any chance of making a special edition for OS X/Yosemite that boosts this limit?

Although I haven't published my research results yet, I do have a whimsical
POV-Ray picture of what I'm up to at

https://cns.utexas.edu/news/visualizing-science-2013

Sincerely,
John Kuehne
McDonald Observatory, Texas

[rfree] Re: UberPOV v1.37.1.0-beta.9 released [4090 days 1 hour and 33 minutes ago]

Sat, 31 Jan 2015 14:35:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Latest UberPOV version, with all the new official POV-Ray bells &
> whistles merged in.
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9

Cool that someone works on this :)

[clipka] UberPOV v1.37.1.0-beta.9 released [4090 days 7 hours and 20 minutes ago]

Sat, 31 Jan 2015 08:47:33 GMT

Latest UberPOV version, with all the new official POV-Ray bells & 
whistles merged in.

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.1.0-beta.9

[Le Forgeron] Re: intersection point [4186 days 4 hours and 28 minutes ago]

Mon, 27 Oct 2014 11:40:10 GMT

Le 27/10/2014 11:52, CAS a Ã©crit :

> I wrote as above,but something was wrong.Maybe how could I modify it?
> 
> 
> 
Please elaborate a bit more on "something was wrong", as my cristal ball
is still in repair and I got no date for its return.

What is your output format ?
Why didn't you provide a fourth function for alpha ?
How is it "wrong" ?

Did your output filename have drive or directory part in it ? (#debug it ?)

-- 
Just because nobody complains does not mean all parachutes are perfect.

[CAS] Re: intersection point [4186 days 5 hours and 13 minutes ago]

Mon, 27 Oct 2014 10:55:01 GMT

Le_Forgeron <lef### [at] freefr> wrote:
> Le 27/10/2014 08:53, CAS a Ã©crit :
> > Hello,I want to consult a question.I want to output the intersection point,but I
> > could not find the function to output the intersection point.I only find the
> > function of PP_Depth.Who can tell me, if I want to output the intersection
> > point,I could choose which function instead of PP_Depth().Thank you for
> > help.Expecting!
> >
> > #version unofficial MegaPOV 1.2;
> > #include "pprocess.inc"
> > #declare DepthMin=0;
> > #declare DepthMax=10
> > global_settings {
> >   assumed_gamma 1.0
> >   post_process{
> >     PP_Depth(DepthMin,DepthMax)
> >     save_file concat("pp_",output_filename(0))
> >   }
> > }
> >
> >
>
> Assuming you are using megapov, it's in the doc:
>
> PP_Init_IPoint_Outputs()
>
> f_output_ipoint_x(x,y)
> f_output_ipoint_y(x,y)
> f_output_ipoint_z(x,y)
>
> http://megapov.inetart.net/manual-1.2.1/megapov0121.html#post_processing
>
>
> --
> Just because nobody complains does not mean all parachutes are perfect.


#version unofficial MegaPOV 1.2;
#include "pprocess.inc"

PP_Init_IPoint_Outputs()
global_settings {
  assumed_gamma 1.0
  post_process{
    function { f_output_ipoint_x(x,y) }
    function { f_output_ipoint_y(x,y) }
    function { f_output_ipoint_z(x,y) }
    save_file concat("pp_",output_filename(0))
  }
}
I wrote as above,but something was wrong.Maybe how could I modify it?

[Le Forgeron] Re: intersection point [4186 days 5 hours and 29 minutes ago]

Mon, 27 Oct 2014 10:39:11 GMT

Le 27/10/2014 08:53, CAS a Ã©crit :
> Hello,I want to consult a question.I want to output the intersection point,but I
> could not find the function to output the intersection point.I only find the
> function of PP_Depth.Who can tell me, if I want to output the intersection
> point,I could choose which function instead of PP_Depth().Thank you for
> help.Expecting!
> 
> #version unofficial MegaPOV 1.2;
> #include "pprocess.inc"
> #declare DepthMin=0;
> #declare DepthMax=10
> global_settings {
>   assumed_gamma 1.0
>   post_process{
>     PP_Depth(DepthMin,DepthMax)
>     save_file concat("pp_",output_filename(0))
>   }
> }
> 
> 

Assuming you are using megapov, it's in the doc:

PP_Init_IPoint_Outputs()

f_output_ipoint_x(x,y)
f_output_ipoint_y(x,y)
f_output_ipoint_z(x,y)

http://megapov.inetart.net/manual-1.2.1/megapov0121.html#post_processing


-- 
Just because nobody complains does not mean all parachutes are perfect.

[CAS] Re: MegaPOV postprocess - possible bug? [4186 days 5 hours and 33 minutes ago]

Mon, 27 Oct 2014 10:35:00 GMT

"Roman Reiner" <lim### [at] gmxde> wrote:
> Hi Guys
>
> I ran into several problems when trying to work with MegaPOV's postprocess
> feature more precicely when trying to use the f_pp_*channel*(x,y,Ref)
> functions. At this time the failures where only that the output did not
> match the functions i wrote. several parts of the calculations inside the
> function blocks seemed to be ignored. for example
> "function { 1-4*f_pp_red(x,y,1) }"
> leaded to the same result as just
> "function { f_pp_red(x,y,1) }"
> namely a simple copy of the image. only changes at the parameters of the
> function made a change (e.g. -x instead of x).
>
> (This problems did however not occur with Ref=0)
>
>
> After further simplifing the code i finally ran into a runtime error.
>
> The source that reproduces the error is:
> <code>
> #version unofficial MegaPOV 1.21;
>
> #include "pprocess.inc"
>
> PP_Init_Alpha_Colors_Outputs()
> PP_Init_PP_Alpha_Colors_Outputs()
>
> global_settings {
>   post_process {
>     function { 1-f_output_red  (x,y) }
>     function { 1-f_output_green(x,y) }
>     function { 1-f_output_blue (x,y) } //(*)
>     function { 1-f_output_alpha(x,y) }
>     save_file "step1.png"
>   }
>   /*post_process {  //<--comment this in
>     function { f_pp_red  (x,y,1) }
>     function { f_pp_green(x,y,1) }
>     function { f_pp_blue (x,y,1) }
>     function { f_pp_alpha(x,y,1) }
>     save_file "step2.png"
>   }*/
> }
> </code>
>
> When the second block is commented in the render stops at the last line of
> the first postprocess step marking the (*) line saying:
> "Parse Error:
> Runtime error detected in function ''. Function evaluation stack underflow."
> The error occurs as well when i use f_pp... with Ref=0 instead of
> f_output... in the first post_process block.
>
> Is this a bug? Or am i just making something wrong? Anyone experiences
> similar problems? Are there workarounds?
>
> Enlightenment wanted :)
> Regards Roman
>
>
> MegaPov 1.2.1 based on POVRay 3.6.1.msvc7.unofficial-win32
> with POVRay 3.6.1.icl8.win32
> WindowsXP Home Edition - Build 2600.xpsp_sp2_gdr.050301-1519 : Service Pack
> 2
> Celeron 2.60GHz - 640MB RAM

Hey,I also want to consult a question.I want to output all the intersection
point .I have wrote some codes as follows,but it always told me something
wrong.I am confusued how can I modify it?

#version unofficial MegaPOV 1.2;
#include "pprocess.inc"

PP_Init_IPoint_X_Output()
PP_Init_IPoint_Y_Output()
PP_Init_IPoint_Z_Output()

global_settings {
  assumed_gamma 1.0
  post_process{
    function { f_output_ipoint_x(x,y) }
    function { f_output_ipoint_y(x,y) }
    function { f_output_ipoint_z(x,y) }
  save_file "step1.png"
  }
}

Regards

[CAS] intersection point [4186 days 8 hours and 13 minutes ago]

Mon, 27 Oct 2014 07:55:00 GMT

Hello,I want to consult a question.I want to output the intersection point,but I
could not find the function to output the intersection point.I only find the
function of PP_Depth.Who can tell me, if I want to output the intersection
point,I could choose which function instead of PP_Depth().Thank you for
help.Expecting!

#version unofficial MegaPOV 1.2;
#include "pprocess.inc"
#declare DepthMin=0;
#declare DepthMax=10
global_settings {
  assumed_gamma 1.0
  post_process{
    PP_Depth(DepthMin,DepthMax)
    save_file concat("pp_",output_filename(0))
  }
}

[clipka] Re: UberPOV does not render shadows of an object... [4218 days 17 hours and 54 minutes ago]

Wed, 24 Sep 2014 22:13:46 GMT

Am 24.09.2014 14:00, schrieb fomhorian:

> I tried rendering the Blink-scene, with or without radiosity, and when rendered
> with UberPOV beta 7 x64 the yellow ball has a shadow but looks strange with
> radiosity on (I used 'no_cache'). UberPOV beta 8 x64 produces no shadow for the
> yellow sphere no matter what, but when radiosity is on the result looks somewhat
> better than with beta 7 (bar the lack of shadow).

I hadn't tested blink with the no_cache radiosity yet, but yes - from 
the images you sent me, it seems seriously broken. But I have a hunch 
why that is, and if I'm right it should be easy to fix.

> A question about the Blink-addon: can I use it on a camera or a light?

No, not at the moment, and in the case of the camera it certainly won't 
be anytime soon - the internal architecture isn't suited to switch 
between cameras while rendering a single frame.

As for light sources, it's probably just a matter of finding a bit of 
time to implement support for blink.

Depending on what you want to achieve, you might be able to simulate 
blinking lights by enclosing the respective light sources in "no_image 
no_reflection no_radiosity" objects that blink just the other way around.

[fomhorian] Re: UberPOV does not render shadows of an object... [4218 days 22 hours and 38 minutes ago]

Wed, 24 Sep 2014 17:30:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 24.09.2014 15:49, schrieb fomhorian:
> > "fomhorian" <fom### [at] gmailcom> wrote:
> >> I tried rendering the Blink-scene, with or without radiosity, and when rendered
> >> with UberPOV beta 7 x64 the yellow ball has a shadow but looks strange with
> >> radiosity on (I used 'no_cache'). UberPOV beta 8 x64 produces no shadow for the
> >> yellow sphere no matter what, but when radiosity is on the result looks somewhat
> >> better than with beta 7 (bar the lack of shadow).
> >>
> >> A question about the Blink-addon: can I use it on a camera or a light?
> >>
> >> @Clipka: I have 5 testrun png's, 400x300. If you want to take a look at them, or
> >> the POV-file, just send me your e-mail address.
> >
> > I have to go grammar-nazi on myself (sorry):
> >
> > -I rendered the Blink-scene, with and without radiosity...
> >
> > Sorry but my OCD kicked in majortime when I reread my own message. :(
>
> Your message did come across ok, so no need to put up with grammar nazis.
>
> I'd like you to send those test png's to Christoph at lipka minus koeln,
> followed by dot de. Thank you!

I think you should have received them by now. :)

[fomhorian] Re: UberPOV does not render shadows of an object... [4218 days 22 hours and 43 minutes ago]

Wed, 24 Sep 2014 17:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 24.09.2014 15:49, schrieb fomhorian:
> > "fomhorian" <fom### [at] gmailcom> wrote:
> >> I tried rendering the Blink-scene, with or without radiosity, and when rendered
> >> with UberPOV beta 7 x64 the yellow ball has a shadow but looks strange with
> >> radiosity on (I used 'no_cache'). UberPOV beta 8 x64 produces no shadow for the
> >> yellow sphere no matter what, but when radiosity is on the result looks somewhat
> >> better than with beta 7 (bar the lack of shadow).
> >>
> >> A question about the Blink-addon: can I use it on a camera or a light?
> >>
> >> @Clipka: I have 5 testrun png's, 400x300. If you want to take a look at them, or
> >> the POV-file, just send me your e-mail address.
> >
> > I have to go grammar-nazi on myself (sorry):
> >
> > -I rendered the Blink-scene, with and without radiosity...
> >
> > Sorry but my OCD kicked in majortime when I reread my own message. :(
>
> Your message did come across ok, so no need to put up with grammar nazis.
>
> I'd like you to send those test png's to Christoph at lipka minus koeln,
> followed by dot de. Thank you!

Is that lipka-koeln, lipkaminuskoeln, lipkakoeln or?

[clipka] Re: UberPOV does not render shadows of an object... [4219 days and 24 minutes ago]

Wed, 24 Sep 2014 15:44:09 GMT

Am 24.09.2014 15:49, schrieb fomhorian:
> "fomhorian" <fom### [at] gmailcom> wrote:
>> I tried rendering the Blink-scene, with or without radiosity, and when rendered
>> with UberPOV beta 7 x64 the yellow ball has a shadow but looks strange with
>> radiosity on (I used 'no_cache'). UberPOV beta 8 x64 produces no shadow for the
>> yellow sphere no matter what, but when radiosity is on the result looks somewhat
>> better than with beta 7 (bar the lack of shadow).
>>
>> A question about the Blink-addon: can I use it on a camera or a light?
>>
>> @Clipka: I have 5 testrun png's, 400x300. If you want to take a look at them, or
>> the POV-file, just send me your e-mail address.
>
> I have to go grammar-nazi on myself (sorry):
>
> -I rendered the Blink-scene, with and without radiosity...
>
> Sorry but my OCD kicked in majortime when I reread my own message. :(

Your message did come across ok, so no need to put up with grammar nazis.

I'd like you to send those test png's to Christoph at lipka minus koeln, 
followed by dot de. Thank you!

[fomhorian] Re: UberPOV does not render shadows of an object... [4219 days 2 hours and 18 minutes ago]

Wed, 24 Sep 2014 13:50:01 GMT

"fomhorian" <fom### [at] gmailcom> wrote:
> I tried rendering the Blink-scene, with or without radiosity, and when rendered
> with UberPOV beta 7 x64 the yellow ball has a shadow but looks strange with
> radiosity on (I used 'no_cache'). UberPOV beta 8 x64 produces no shadow for the
> yellow sphere no matter what, but when radiosity is on the result looks somewhat
> better than with beta 7 (bar the lack of shadow).
>
> A question about the Blink-addon: can I use it on a camera or a light?
>
> @Clipka: I have 5 testrun png's, 400x300. If you want to take a look at them, or
> the POV-file, just send me your e-mail address.

I have to go grammar-nazi on myself (sorry):

-I rendered the Blink-scene, with and without radiosity...

Sorry but my OCD kicked in majortime when I reread my own message. :(

[fomhorian] Re: UberPOV does not render shadows of an object... [4219 days 4 hours and 3 minutes ago]

Wed, 24 Sep 2014 12:05:01 GMT

"Ard" <and### [at] gmailcom> wrote:
> > For starters, I can confirm that this is entirely unintended, and
> > therefore a bug indeed.
> >
> > As an admittedly very counter-intuitive workaround, the shadows can be
> > made to re-appear by making the pigment slightly transparent. (Any value
> > larger than the adc_bailout value will do.)
>
> Thank you!  And to FractRacer.  0.004 transparency added, a refresher in the
> difference between rgbf and rgbt and why the former only brought part of my
> shadows back, and I'm good.

I tried rendering the Blink-scene, with or without radiosity, and when rendered
with UberPOV beta 7 x64 the yellow ball has a shadow but looks strange with
radiosity on (I used 'no_cache'). UberPOV beta 8 x64 produces no shadow for the
yellow sphere no matter what, but when radiosity is on the result looks somewhat
better than with beta 7 (bar the lack of shadow).

A question about the Blink-addon: can I use it on a camera or a light?

@Clipka: I have 5 testrun png's, 400x300. If you want to take a look at them, or
the POV-file, just send me your e-mail address.

[Ard] Re: UberPOV does not render shadows of an object... [4219 days 8 hours and 3 minutes ago]

Wed, 24 Sep 2014 08:05:01 GMT

> For starters, I can confirm that this is entirely unintended, and
> therefore a bug indeed.
>
> As an admittedly very counter-intuitive workaround, the shadows can be
> made to re-appear by making the pigment slightly transparent. (Any value
> larger than the adc_bailout value will do.)

Thank you!  And to FractRacer.  0.004 transparency added, a refresher in the
difference between rgbf and rgbt and why the former only brought part of my
shadows back, and I'm good.

[FractRacer] Re: UberPOV does not render shadows of an object... [4220 days 1 hour and 4 minutes ago]

Tue, 23 Sep 2014 15:03:18 GMT

Le 23/09/2014 12:41, Ard a écrit :
> Hi folks.  Hope you can help.  The two boxes in this scene cast shadows onto the
> usual plane when I render it with vanilla POV-Ray, but UberPOV does not cast a
> shadow behind the one with the texture map.
>
> Uber build 1.37.1.0-beta.8.msvc10.win64
>
> scenes/textures/pigments/txtrmap.pov also renders differently, which makes me
> think this is more likely to be a bug than my doing something dumb, but I will
> take either.
>
> Sorry not to chase this down and submit a patch myself, but the last time I
> looked at this tracer it was called DKB!
>
> Thanks in advance.  Scene follows:
>
>
> camera { location <0, 5, -5> look_at 0}
> plane {  y, -2 texture { pigment { checker colour rgb y colour rgb z} }}
> light_source { <2.5, 5.5, -3> rgb 1 }
>
> box { -1, 1
>    texture { wood
>      texture_map {
>        [ 0 pigment { rgb 0.5 } ]
>        [ 1 pigment { rgb 1 } ]
>      } } }
>
> box { 0 2 pigment {rgb x} }
>
>

I have rendered this scene with UberPov 1.37.0.0-beta.6.mscv10 win32bits 
and with pov-sse32 and there is no difference.




-- 
Do not judge my words, judge my actions.

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.com

[clipka] Re: UberPOV does not render shadows of an object... [4220 days 4 hours and 25 minutes ago]

Tue, 23 Sep 2014 11:43:08 GMT

Am 23.09.2014 12:41, schrieb Ard:
> Hi folks.  Hope you can help.  The two boxes in this scene cast shadows onto the
> usual plane when I render it with vanilla POV-Ray, but UberPOV does not cast a
> shadow behind the one with the texture map.
>
> Uber build 1.37.1.0-beta.8.msvc10.win64
>
> scenes/textures/pigments/txtrmap.pov also renders differently, which makes me
> think this is more likely to be a bug than my doing something dumb, but I will
> take either.

For starters, I can confirm that this is entirely unintended, and 
therefore a bug indeed.

As an admittedly very counter-intuitive workaround, the shadows can be 
made to re-appear by making the pigment slightly transparent. (Any value 
larger than the adc_bailout value will do.)

[Ard] UberPOV does not render shadows of an object wit... [4220 days 5 hours and 23 minutes ago]

Tue, 23 Sep 2014 10:45:01 GMT

Hi folks.  Hope you can help.  The two boxes in this scene cast shadows onto the
usual plane when I render it with vanilla POV-Ray, but UberPOV does not cast a
shadow behind the one with the texture map.

Uber build 1.37.1.0-beta.8.msvc10.win64

scenes/textures/pigments/txtrmap.pov also renders differently, which makes me
think this is more likely to be a bug than my doing something dumb, but I will
take either.

Sorry not to chase this down and submit a patch myself, but the last time I
looked at this tracer it was called DKB!

Thanks in advance.  Scene follows:


camera { location <0, 5, -5> look_at 0}
plane {  y, -2 texture { pigment { checker colour rgb y colour rgb z} }}
light_source { <2.5, 5.5, -3> rgb 1 }

box { -1, 1
  texture { wood
    texture_map {
      [ 0 pigment { rgb 0.5 } ]
      [ 1 pigment { rgb 1 } ]
    } } }

box { 0 2 pigment {rgb x} }

[jhu] Re: Unable to compile Uberpov on FreeBSD 10 [4226 days 17 hours and 3 minutes ago]

Tue, 16 Sep 2014 23:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 16.09.2014 19:25, schrieb jhu:
>
> > Now I get:
> >
> > backend/povray.cpp:30:115 error: expected ')' before 'SSE2_INCLUDED'
> >       BRANCH_FULL_NAME STANDALONE_VER " Version %s", BRANCH_FULL_VERSION
> > COMPILER_VER SSE2_INCLUDED);
>
> Something's wrong there - povray.cpp line 30 is right within the header
> comment, and (of course) reads entirely different.

Got rid of the SSE2_INCLUDED and it compiles now.

[clipka] Re: Unable to compile Uberpov on FreeBSD 10 [4226 days 21 hours and 18 minutes ago]

Tue, 16 Sep 2014 18:49:44 GMT

Am 16.09.2014 19:25, schrieb jhu:

> Now I get:
>
> backend/povray.cpp:30:115 error: expected ')' before 'SSE2_INCLUDED'
>       BRANCH_FULL_NAME STANDALONE_VER " Version %s", BRANCH_FULL_VERSION
> COMPILER_VER SSE2_INCLUDED);

Something's wrong there - povray.cpp line 30 is right within the header 
comment, and (of course) reads entirely different.

[jhu] Re: Unable to compile Uberpov on FreeBSD 10 [4226 days 22 hours and 38 minutes ago]

Tue, 16 Sep 2014 17:30:00 GMT

"jhu" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> > This is probably also code that's not actually used yet.
> >
> >
> > I hate BSD (and GNU/Linux, for that matter). They keep exposing sloppy
> > non-ANSI-compliant code that works so nicely on Windows. :-P
> >
> >
> > If the above works for you, please remind me to add the fix to UberPOV
> > or POV-Ray, wherever that code originates from.
>
> Thanks that works so far, until...
> depbase=`echo base/colour.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; g++
> -DHAVE_CONFIG_H -I. -I..   -I..  -I../source/backend  -I../source/base
> -I../source/frontend  -I../unix  -I../vfe  -I../vfe/unix
> -I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT
> -D_THREAD_SAFE  -pthread -I/usr/local/include  -I/usr/include  -pipe
> -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -Wno-non-template-friend
> -s -O3 -ffast-math -D_THREAD_SAFE -pthread -MT base/colour.o -MD -MP -MF
> $depbase.Tpo -c -o base/colour.o base/colour.cpp && mv -f $depbase.Tpo
> $depbase.Po
> base/colour.cpp: In instantiation of 'static void
> pov_base::ColourModelInternal4::MetamericNormalize(CHANNEL_T*) [with CHANNEL_T =
> float; MODEL_FROM_T = pov_base::ColourModelRGB]':
> base/colour.cpp:148:119:   required from here
> base/colour.cpp:54:86: error: dependent-name 'MODEL_FROM_T:: Whitepoint' is
> parsed as a non-type, but instantiation yields a type
>      const ColourChannel* pWhitepoint =
> GetWhitepointVector<MODEL_FROM_T::Whitepoint>();
>
>      ^
> base/colour.cpp:54:86: note: say 'typename MODEL_FROM_T:: Whitepoint' if a type
> is meant
> base/colour.cpp: In instantiation of 'static void
> pov_base::ColourModelInternal4::MetamericNormalize(CHANNEL_T*) [with CHANNEL_T =
> double; MODEL_FROM_T = pov_base::ColourModelRGB]':
> base/colour.cpp:149:119:   required from here
> base/colour.cpp:54:86: error: dependent-name 'MODEL_FROM_T:: Whitepoint' is
> parsed as a non-type, but instantiation yields a type
> base/colour.cpp:54:86: note: say 'typename MODEL_FROM_T:: Whitepoint' if a type
> is meant
> *** Error code 1

Ok, solved this by doing what the compiler note says (add typename).

Now I get:

backend/povray.cpp:30:115 error: expected ')' before 'SSE2_INCLUDED'
     BRANCH_FULL_NAME STANDALONE_VER " Version %s", BRANCH_FULL_VERSION
COMPILER_VER SSE2_INCLUDED);

[jhu] Re: Unable to compile Uberpov on FreeBSD 10 [4227 days 1 hour and 23 minutes ago]

Tue, 16 Sep 2014 14:45:01 GMT

clipka <ano### [at] anonymousorg> wrote:

> This is probably also code that's not actually used yet.
>
>
> I hate BSD (and GNU/Linux, for that matter). They keep exposing sloppy
> non-ANSI-compliant code that works so nicely on Windows. :-P
>
>
> If the above works for you, please remind me to add the fix to UberPOV
> or POV-Ray, wherever that code originates from.

Thanks that works so far, until...
depbase=`echo base/colour.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; g++
-DHAVE_CONFIG_H -I. -I..   -I..  -I../source/backend  -I../source/base
-I../source/frontend  -I../unix  -I../vfe  -I../vfe/unix
-I/usr/local/include/SDL -I/usr/local/include -D_GNU_SOURCE=1 -D_REENTRANT
-D_THREAD_SAFE  -pthread -I/usr/local/include  -I/usr/include  -pipe
-Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -Wno-non-template-friend
-s -O3 -ffast-math -D_THREAD_SAFE -pthread -MT base/colour.o -MD -MP -MF
$depbase.Tpo -c -o base/colour.o base/colour.cpp && mv -f $depbase.Tpo
$depbase.Po
base/colour.cpp: In instantiation of 'static void
pov_base::ColourModelInternal4::MetamericNormalize(CHANNEL_T*) [with CHANNEL_T =
float; MODEL_FROM_T = pov_base::ColourModelRGB]':
base/colour.cpp:148:119:   required from here
base/colour.cpp:54:86: error: dependent-name 'MODEL_FROM_T:: Whitepoint' is
parsed as a non-type, but instantiation yields a type
     const ColourChannel* pWhitepoint =
GetWhitepointVector<MODEL_FROM_T::Whitepoint>();

     ^
base/colour.cpp:54:86: note: say 'typename MODEL_FROM_T:: Whitepoint' if a type
is meant
base/colour.cpp: In instantiation of 'static void
pov_base::ColourModelInternal4::MetamericNormalize(CHANNEL_T*) [with CHANNEL_T =
double; MODEL_FROM_T = pov_base::ColourModelRGB]':
base/colour.cpp:149:119:   required from here
base/colour.cpp:54:86: error: dependent-name 'MODEL_FROM_T:: Whitepoint' is
parsed as a non-type, but instantiation yields a type
base/colour.cpp:54:86: note: say 'typename MODEL_FROM_T:: Whitepoint' if a type
is meant
*** Error code 1

[clipka] Re: Unable to compile Uberpov on FreeBSD 10 [4227 days 8 hours and 2 minutes ago]

Tue, 16 Sep 2014 08:05:36 GMT

Am 16.09.2014 03:55, schrieb jhu:
> It compiles fine on Ubuntu 14.04. On FreeBSD 10, using gcc 4.8, I get the
> following:
>
> depbase=`echo optout.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; g++ -DHAVE_CONFIG_H
> -I. -I..   -I..  -I../source/backend  -I../source/base  -I../source/frontend
> -I../unix  -I../vfe  -I../vfe/unix -I/usr/local/include/SDL -I/usr/local/include
> -D_GNU_SOURCE=1 -D_REENTRANT -D_THREAD_SAFE -pthread
> -I/usr/local/include/OpenEXR    -pthread -I/usr/local/include  -I/usr/include
> -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
> -Wno-non-template-friend -s -O3 -ffast-math -D_THREAD_SAFE -pthread -MT optout.o
> -MD -MP -MF $depbase.Tpo -c -o optout.o optout.cpp && mv -f $depbase.Tpo
> $depbase.Po
> In file included from backend/frame.h:67:0,
>                   from optout.cpp:42:
> .../base/colour.h: In member function 'pov_base::GenericTrans<COLOUR_T>::Channel
> pov_base::GenericTrans<COLOUR_T>::LegacyOpacity(const Colour&) const':
> .../base/colour.h:1132:28: error: 'col' was not declared in this scope
>               return Opacity(col);
>                              ^

Ah, dammit... looks like the compiler is trying to compile a template 
that isn't even used yet, and therefore poorly tested...

Try changing line 1130 (!) from

         inline Channel LegacyOpacity(const Colour&) const

to

         inline Channel LegacyOpacity(const Colour& col) const


> In file included from backend/frame.h:67:0,
>                   from optout.cpp:42:
> .../base/colour.h: In constructor
> 'pov_base::GenericTransColour<CT>::GenericTransColour(const Colour&,
> pov_base::GenericTransColour<CT>::Channel,
> pov_base::GenericTransColour<CT>::Channel)':
> .../base/colour.h:1933:13: error: class 'pov_base::GenericTransColour<CT>' does
> not have any field named 'mFilter'
>               mFilter(filter),
>               ^
> .../base/colour.h:1934:13: error: class 'pov_base::GenericTransColour<CT>' does
> not have any field named 'mTransm'
>               mTransm(transm)
>               ^

Try chaning lines 1933 and 1934 from

             mFilter(filter),
             mTransm(transm)

to

             mTrans(filter, transm)

This is probably also code that's not actually used yet.


I hate BSD (and GNU/Linux, for that matter). They keep exposing sloppy 
non-ANSI-compliant code that works so nicely on Windows. :-P


If the above works for you, please remind me to add the fix to UberPOV 
or POV-Ray, wherever that code originates from.

[jhu] Unable to compile Uberpov on FreeBSD 10 [4227 days 14 hours and 8 minutes ago]

Tue, 16 Sep 2014 02:00:00 GMT

It compiles fine on Ubuntu 14.04. On FreeBSD 10, using gcc 4.8, I get the
following:

depbase=`echo optout.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`; g++ -DHAVE_CONFIG_H
-I. -I..   -I..  -I../source/backend  -I../source/base  -I../source/frontend
-I../unix  -I../vfe  -I../vfe/unix -I/usr/local/include/SDL -I/usr/local/include
-D_GNU_SOURCE=1 -D_REENTRANT -D_THREAD_SAFE -pthread
-I/usr/local/include/OpenEXR    -pthread -I/usr/local/include  -I/usr/include
-pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
-Wno-non-template-friend -s -O3 -ffast-math -D_THREAD_SAFE -pthread -MT optout.o
-MD -MP -MF $depbase.Tpo -c -o optout.o optout.cpp && mv -f $depbase.Tpo
$depbase.Po
In file included from backend/frame.h:67:0,
                 from optout.cpp:42:
../base/colour.h: In member function 'pov_base::GenericTrans<COLOUR_T>::Channel
pov_base::GenericTrans<COLOUR_T>::LegacyOpacity(const Colour&) const':
../base/colour.h:1132:28: error: 'col' was not declared in this scope
             return Opacity(col);
                            ^
In file included from backend/frame.h:67:0,
                 from optout.cpp:42:
../base/colour.h: In constructor
'pov_base::GenericTransColour<CT>::GenericTransColour(const Colour&,
pov_base::GenericTransColour<CT>::Channel,
pov_base::GenericTransColour<CT>::Channel)':
../base/colour.h:1933:13: error: class 'pov_base::GenericTransColour<CT>' does
not have any field named 'mFilter'
             mFilter(filter),
             ^
../base/colour.h:1934:13: error: class 'pov_base::GenericTransColour<CT>' does
not have any field named 'mTransm'
             mTransm(transm)
             ^
*** Error code 1

Stop.
make[2]: stopped in /tank/jhu/temp/UberPOV-master/source
*** Error code 1

Stop.
make[1]: stopped in /tank/jhu/temp/UberPOV-master
*** Error code 1

Stop.

Should there be something in front of 'col'? And what to do about mFilter and
mTransm?

[jhu] Re: Is anyone working on a distributed / stochas... [4241 days 2 hours and 13 minutes ago]

Tue, 2 Sep 2014 13:55:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 01.09.2014 18:16, schrieb jhu:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 24.07.2014 17:58, schrieb Nekar Xenos:
> >>> On Wed, 23 Jul 2014 21:52:32 +0200, clipka <ano### [at] anonymousorg> wrote:
> >>>
> >>>
> >>>> (Actually it's not /that/ much of a coincidence: As a first approach
> >>>> at "replacing" radiosity I plan to actually just keep using it but not
> >>>> cache the results (plus make sure that the secondary rays shot are
> >>>> different each time); and as I want UberPOV to fully support
> >>>> non-default brilliance settings, I figured that I might just as well
> >>>> add that to POV-Ray's radiosity first... And then one thing led to
> >>>> another, and I found myself adding all those fancy finish improvements
> >>>> that had been on my agenda for so long...)
> >>>>
> >>>
> >>> You're our hero :)
> >>
> >> Thanks. Sometimes I am. ;-)
> >
> > How difficult would it be to adapt this to GPU rendering via OpenCL or CUDA?
>
> Very. At least that's what I still suspect.

Oh well. Knight's Landing is just around the corner so OpenCL/CUDA might be
moot, but hopefully it's not too expensive.

[clipka] Re: Is anyone working on a distributed / stochas... [4241 days 20 hours and 10 minutes ago]

Mon, 1 Sep 2014 19:57:39 GMT

Am 01.09.2014 18:16, schrieb jhu:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 24.07.2014 17:58, schrieb Nekar Xenos:
>>> On Wed, 23 Jul 2014 21:52:32 +0200, clipka <ano### [at] anonymousorg> wrote:
>>>
>>>
>>>> (Actually it's not /that/ much of a coincidence: As a first approach
>>>> at "replacing" radiosity I plan to actually just keep using it but not
>>>> cache the results (plus make sure that the secondary rays shot are
>>>> different each time); and as I want UberPOV to fully support
>>>> non-default brilliance settings, I figured that I might just as well
>>>> add that to POV-Ray's radiosity first... And then one thing led to
>>>> another, and I found myself adding all those fancy finish improvements
>>>> that had been on my agenda for so long...)
>>>>
>>>
>>> You're our hero :)
>>
>> Thanks. Sometimes I am. ;-)
>
> How difficult would it be to adapt this to GPU rendering via OpenCL or CUDA?

Very. At least that's what I still suspect.

[jhu] Re: Is anyone working on a distributed / stochas... [4241 days 23 hours and 48 minutes ago]

Mon, 1 Sep 2014 16:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 24.07.2014 17:58, schrieb Nekar Xenos:
> > On Wed, 23 Jul 2014 21:52:32 +0200, clipka <ano### [at] anonymousorg> wrote:
> >
> >
> >> (Actually it's not /that/ much of a coincidence: As a first approach
> >> at "replacing" radiosity I plan to actually just keep using it but not
> >> cache the results (plus make sure that the secondary rays shot are
> >> different each time); and as I want UberPOV to fully support
> >> non-default brilliance settings, I figured that I might just as well
> >> add that to POV-Ray's radiosity first... And then one thing led to
> >> another, and I found myself adding all those fancy finish improvements
> >> that had been on my agenda for so long...)
> >>
> >
> > You're our hero :)
>
> Thanks. Sometimes I am. ;-)

How difficult would it be to adapt this to GPU rendering via OpenCL or CUDA?

[scott] Re: UberPOV v1.37.0.0-beta.6 released [4245 days 9 hours and 13 minutes ago]

Fri, 29 Aug 2014 06:55:13 GMT

>>>> That aside, you can always specify a custom seed (or, more precisely,
>>>> seed base, as UberPOV will still add the thread number to it) using the
>>>> "+SSn" or "Stochastic_Seed=n" option.
>>>
>>> It doesn't recognise the +SS option here (beta 7 release).
>>
>> Dang. Forget everything I've said; I just notice that I haven't built
>> any Windows beta yet that includes those changes; in beta 7, the RNG is
>> indeed seeded with a default value. Help is on the way, expect a new
>> beta release later tonight.
>
> Done.

Excellent thanks :-)

[clipka] Re: UberPOV v1.37.0.0-beta.6 released [4245 days 16 hours and 3 minutes ago]

Fri, 29 Aug 2014 00:04:51 GMT

Am 28.08.2014 18:34, schrieb clipka:
> Am 28.08.2014 11:12, schrieb scott:
>
>>> That aside, you can always specify a custom seed (or, more precisely,
>>> seed base, as UberPOV will still add the thread number to it) using the
>>> "+SSn" or "Stochastic_Seed=n" option.
>>
>> It doesn't recognise the +SS option here (beta 7 release).
>
> Dang. Forget everything I've said; I just notice that I haven't built
> any Windows beta yet that includes those changes; in beta 7, the RNG is
> indeed seeded with a default value. Help is on the way, expect a new
> beta release later tonight.

Done.

[clipka] Re: UberPOV v1.37.0.0-beta.6 released [4245 days 23 hours and 33 minutes ago]

Thu, 28 Aug 2014 16:34:35 GMT

Am 28.08.2014 11:12, schrieb scott:

>> That aside, you can always specify a custom seed (or, more precisely,
>> seed base, as UberPOV will still add the thread number to it) using the
>> "+SSn" or "Stochastic_Seed=n" option.
>
> It doesn't recognise the +SS option here (beta 7 release).

Dang. Forget everything I've said; I just notice that I haven't built 
any Windows beta yet that includes those changes; in beta 7, the RNG is 
indeed seeded with a default value. Help is on the way, expect a new 
beta release later tonight.

[scott] Re: UberPOV v1.37.0.0-beta.6 released [4246 days 6 hours and 48 minutes ago]

Thu, 28 Aug 2014 09:19:39 GMT

On 28/08/2014 10:12, scott wrote:
>> By default UberPOV will seed each thread's stochastic RNG with the
>> current time plus thread number,
>
> Hmmm, something strange is going on, when I look at the difference
> between the exact same scene rendered a few minutes apart there are
> about 10% of blocks that are totally identical, the rest are random
> noise. See image I just posted to p.b.i.

If I reduce the thread count to 1 then it's only the first top-left 
block that is identical - the rest of the image is random.

[scott] Re: UberPOV v1.37.0.0-beta.6 released [4246 days 6 hours and 55 minutes ago]

Thu, 28 Aug 2014 09:12:34 GMT

> By default UberPOV will seed each thread's stochastic RNG with the
> current time plus thread number,

Hmmm, something strange is going on, when I look at the difference 
between the exact same scene rendered a few minutes apart there are 
about 10% of blocks that are totally identical, the rest are random 
noise. See image I just posted to p.b.i.

> That aside, you can always specify a custom seed (or, more precisely,
> seed base, as UberPOV will still add the thread number to it) using the
> "+SSn" or "Stochastic_Seed=n" option.

It doesn't recognise the +SS option here (beta 7 release).

[Le Forgeron] Re: problem about MegaPov [4246 days 9 hours and 39 minutes ago]

Thu, 28 Aug 2014 06:29:14 GMT

Le 27/08/2014 17:40, CAS a Ã©crit :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> On 26/08/2014 06:54, CAS wrote:
>>
>>> Thank you for your help.I have
foundÃ¢â‚¬Å“postproc.cppÃ¢â‚¬Âand
commented out the line
>>> 360,but there are many problems when I compiled.I have a beg,could you please
>>> give me a compiled MegaPOV-1.2.1-windows.zip which have commented out the line
>>> 360.I need to set up modified MegaPOV-1.2.1-windows currently.Sorry to bring you
>>> so much teouble!Thank you and expecting your reply! Best wishes!
>>>
>> Well, sorry but I have no windows system to generate such binary.
>> Maybe someone else can help ?
>>
>> --
>> IQ of crossposters with FU: 100 / (number of groups)
>> IQ of crossposters without FU: 100 / (1 + number of groups)
>> IQ of multiposters: 100 / ( (number of groups) * (number of groups))
> 
> Anyway,I am very grateful to you.I have solved this problem.However,I
> encountered a new problem.I need to generate ancillary image planes with
> MegaPov.Such as:
> â€¢ Colors (Red, Green, Blue and Alpha).
> â€¢ The intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and
z(ix,iy).
> â€¢ Surface normals n(ix,iy) at the intersection point.
> â€¢ Distance d(ix,iy) between camera and intersection point.
> I found that the output rendered by MegaPov is the same as POV,that means no
> difference with POV. How can I make MegaPov output auxiliary images such as
> above I listed? Beg a hot!Thanks and expecting reply! Best wishes!
> 
> 
> 
It seems to be in the doc:

http://megapov.inetart.net/manual-1.2.1/megapov0121.html#post_processing

Read it carefully and slowly. (hint: global_settings)

-- 
Just because nobody complains does not mean all parachutes are perfect.

[CAS] Re: problem about MegaPov [4247 days and 23 minutes ago]

Wed, 27 Aug 2014 15:45:00 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> On 26/08/2014 06:54, CAS wrote:
>
> > Thank you for your help.I have
foundâ€œpostproc.cppâ€and commented out the line
> > 360,but there are many problems when I compiled.I have a beg,could you please
> > give me a compiled MegaPOV-1.2.1-windows.zip which have commented out the line
> > 360.I need to set up modified MegaPOV-1.2.1-windows currently.Sorry to bring you
> > so much teouble!Thank you and expecting your reply! Best wishes!
> >
> Well, sorry but I have no windows system to generate such binary.
> Maybe someone else can help ?
>
> --
> IQ of crossposters with FU: 100 / (number of groups)
> IQ of crossposters without FU: 100 / (1 + number of groups)
> IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Anyway,I am very grateful to you.I have solved this problem.However,I
encountered a new problem.I need to generate ancillary image planes with
MegaPov.Such as:
• Colors (Red, Green, Blue and Alpha).
• The intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and z(ix,iy).
• Surface normals n(ix,iy) at the intersection point.
• Distance d(ix,iy) between camera and intersection point.
I found that the output rendered by MegaPov is the same as POV,that means no
difference with POV. How can I make MegaPov output auxiliary images such as
above I listed? Beg a hot!Thanks and expecting reply! Best wishes!

[clipka] Re: UberPOV v1.37.0.0-beta.6 released [4247 days and 38 minutes ago]

Wed, 27 Aug 2014 15:29:22 GMT

Am 27.08.2014 08:57, schrieb scott:
>>>> I found under some conditions you get a visible pattern to the noise
>>>> when doing a low quality "preview" render with no_cache. It's almost as
>>>> if the random number generator is seeded off the pixel coordinate or
>>>> something? Is this possible or am I seeing patterns where none exist?
>>>>
>>>
>>> A simple way to check that: Launch a 2 or 3 frames animation with no
>>> changes between the frames.
>>> If there is a repeatable pattern, the images will show the same pattern.
>>> If the pattern is just random noise, it will change from frame to frame.
>>
>> OK it's the same every frame, I'll post an image in p.b.i.
>
> Actually I just realised this has an implication, that you can't render
> N times on one machine (or I assume on N machines) and then average the
> result. Should there be a way to set the RNG seed that is used for
> choosing the direction to shoot rays?

By default UberPOV will seed each thread's stochastic RNG with the 
current time plus thread number, but I guess I should change this so 
that a render started 1 second later doesn't give you the same seeds for 
threads 1..N as the previous one for threads 0..(N-1), and I should also 
look into why this doesn't seem to work for animations.

That aside, you can always specify a custom seed (or, more precisely, 
seed base, as UberPOV will still add the thread number to it) using the 
"+SSn" or "Stochastic_Seed=n" option.

[scott] Re: UberPOV v1.37.0.0-beta.6 released [4247 days 9 hours and 10 minutes ago]

Wed, 27 Aug 2014 06:57:29 GMT

>>> I found under some conditions you get a visible pattern to the noise
>>> when doing a low quality "preview" render with no_cache. It's almost as
>>> if the random number generator is seeded off the pixel coordinate or
>>> something? Is this possible or am I seeing patterns where none exist?
>>>
>>
>> A simple way to check that: Launch a 2 or 3 frames animation with no
>> changes between the frames.
>> If there is a repeatable pattern, the images will show the same pattern.
>> If the pattern is just random noise, it will change from frame to frame.
>
> OK it's the same every frame, I'll post an image in p.b.i.

Actually I just realised this has an implication, that you can't render 
N times on one machine (or I assume on N machines) and then average the 
result. Should there be a way to set the RNG seed that is used for 
choosing the direction to shoot rays?

[Le Forgeron] Re: problem about MegaPov [4247 days 23 hours and 16 minutes ago]

Tue, 26 Aug 2014 16:51:32 GMT

On 26/08/2014 06:54, CAS wrote:

> Thank you for your help.I have
foundâ€œpostproc.cppâ€and commented out the line
> 360,but there are many problems when I compiled.I have a beg,could you please
> give me a compiled MegaPOV-1.2.1-windows.zip which have commented out the line
> 360.I need to set up modified MegaPOV-1.2.1-windows currently.Sorry to bring you
> so much teouble!Thank you and expecting your reply! Best wishes!
> 
Well, sorry but I have no windows system to generate such binary.
Maybe someone else can help ?

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

[CAS] Re: problem about MegaPov [4248 days 11 hours and 13 minutes ago]

Tue, 26 Aug 2014 04:55:01 GMT

Le_Forgeron <jgr### [at] freefr> wrote:
> On 25/08/2014 09:08, CAS wrote:
> > Recently,I am interested in generating ancillary image planes with MegaPov.Such
> > as follows:
> > â€¢ Colors (Red, Green, Blue and Alpha).
> > â€¢ The intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and
z(ix,iy).
> > â€¢ Surface normals n(ix,iy) at the intersection point.
> > â€¢ Distance d(ix,iy) between camera and intersection point.
> >
> > An article says:â€œNote that in order for the image planes to be
available to the
> > user, a statement to delete the files in the
programâ€œpostproc.cppâ€ for MegaPOV
> > version 1.2.1 on line 360 must be commented out, otherwise the files which have
> > the extension PPD are deleted after the rendering is completed.â€
I have set up
> > MegaPOV version 1.2.1 and pov-ray 3.6.I want to know how can I get ancillary
> > image planes with MegaPov. I did not find the program
â€œpostproc.cppâ€.Can
> > somebody tell me how can I do? Thanks and expecting reply! Best wishes!
> >
>
>
> You need the sources of megapov 1.2.1 (
> > http://megapov.inetart.net/packages/unix/megapov-1.2.1.tar.bz2
>
> )
>
> Then the file is ./source/patches/postproc.cpp
>
> Once changed, you "just" have to compile your version of megapov.
>
> --
> IQ of crossposters with FU: 100 / (number of groups)
> IQ of crossposters without FU: 100 / (1 + number of groups)
> IQ of multiposters: 100 / ( (number of groups) * (number of groups))

Thank you for your help.I have found“postproc.cpp”and commented out the line
360,but there are many problems when I compiled.I have a beg,could you please
give me a compiled MegaPOV-1.2.1-windows.zip which have commented out the line
360.I need to set up modified MegaPOV-1.2.1-windows currently.Sorry to bring you
so much teouble!Thank you and expecting your reply! Best wishes!

[Le Forgeron] Re: problem about MegaPov [4248 days 22 hours and 19 minutes ago]

Mon, 25 Aug 2014 17:49:06 GMT

On 25/08/2014 09:08, CAS wrote:
> Recently,I am interested in generating ancillary image planes with MegaPov.Such
> as follows:
> â€¢ Colors (Red, Green, Blue and Alpha).
> â€¢ The intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and
z(ix,iy).
> â€¢ Surface normals n(ix,iy) at the intersection point.
> â€¢ Distance d(ix,iy) between camera and intersection point.
> 
> An article says:â€œNote that in order for the image planes to be
available to the
> user, a statement to delete the files in the
programâ€œpostproc.cppâ€ for MegaPOV
> version 1.2.1 on line 360 must be commented out, otherwise the files which have
> the extension PPD are deleted after the rendering is completed.â€ I
have set up
> MegaPOV version 1.2.1 and pov-ray 3.6.I want to know how can I get ancillary
> image planes with MegaPov. I did not find the program
â€œpostproc.cppâ€.Can
> somebody tell me how can I do? Thanks and expecting reply! Best wishes!
> 


You need the sources of megapov 1.2.1 (
> http://megapov.inetart.net/packages/unix/megapov-1.2.1.tar.bz2

)

Then the file is ./source/patches/postproc.cpp

Once changed, you "just" have to compile your version of megapov.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

[Alain] Re: problem about MegaPov [4248 days 22 hours and 22 minutes ago]

Mon, 25 Aug 2014 17:45:43 GMT

Le 14-08-25 03:08, CAS a écrit :
> Recently,I am interested in generating ancillary image planes with MegaPov.Such
> as follows:
> • Colors (Red, Green, Blue and Alpha).
> • The intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and z(ix,iy).
> • Surface normals n(ix,iy) at the intersection point.
> • Distance d(ix,iy) between camera and intersection point.
>
> An article says:“Note that in order for the image planes to be available to the
> user, a statement to delete the files in the program“postproc.cpp” for
MegaPOV
> version 1.2.1 on line 360 must be commented out, otherwise the files which have
> the extension PPD are deleted after the rendering is completed.” I have set up
> MegaPOV version 1.2.1 and pov-ray 3.6.I want to know how can I get ancillary
> image planes with MegaPov. I did not find the program “postproc.cpp”.Can
> somebody tell me how can I do? Thanks and expecting reply! Best wishes!
>
>
>

postproc.cpp is NOT a programm but a C++ source file.

To do what you want, you need to get the source files, edit the line 
360, and compile the executable.

You'll obviously need to get a C++ compiler with all the needed libraries.


Alain

[CAS] problem about MegaPov [4249 days 8 hours and 58 minutes ago]

Mon, 25 Aug 2014 07:10:01 GMT

Recently,I am interested in generating ancillary image planes with MegaPov.Such
as follows:
• Colors (Red, Green, Blue and Alpha).
• The intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and z(ix,iy).
• Surface normals n(ix,iy) at the intersection point.
• Distance d(ix,iy) between camera and intersection point.

An article says:“Note that in order for the image planes to be available to the
user, a statement to delete the files in the program“postproc.cpp” for
MegaPOV
version 1.2.1 on line 360 must be commented out, otherwise the files which have
the extension PPD are deleted after the rendering is completed.” I have set up
MegaPOV version 1.2.1 and pov-ray 3.6.I want to know how can I get ancillary
image planes with MegaPov. I did not find the program “postproc.cpp”.Can
somebody tell me how can I do? Thanks and expecting reply! Best wishes!

[clipka] Re: stl file generation [4255 days 15 hours and 30 minutes ago]

Tue, 19 Aug 2014 00:37:33 GMT

Am 18.08.2014 21:49, schrieb Le_Forgeron:

> The output works with Shapeways.

That's some pretty good news.

[Le Forgeron] stl file generation [4255 days 20 hours and 18 minutes ago]

Mon, 18 Aug 2014 19:49:58 GMT

To make my life easier, Hgpovray (
https://github.com/LeForgeron/povray/tree/Hgpovray
) can now generate a stl file from a (closed) mesh.

Still have to document it, but syntax is :

  stl_save { "filename.stl" , MeshObject }

Code should run on little endian and big endian.
(but I have only a little endian to test)

The output works with Shapeways.

-- 
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))

[Jaime Vives Piqueres] Re: Error compiling UberPOV master [4259 days 23 hours and 3 minutes ago]

Thu, 14 Aug 2014 17:04:59 GMT

El 14/08/14 a las #4, clipka escribiÃ³:
> Am 14.08.2014 16:12, schrieb Jaime Vives Piqueres:
>
>> That worked, thanks... I was trying to test the persistent
>> variables with an animation of my bullet physics car, and it worked
>> great: making the big meshes persistent, I've reduced the frame
>> render times from 10-11s to 2-3s! So, the 11h render should be
>> ready now in just 3h.
>
> Hey, that's cool :-)
>

   Yeah, indeed... animations with big meshes are now very reasonable,
while before the parsing time would turn you away.

--
jaime

[clipka] Re: Error compiling UberPOV master [4259 days 23 hours and 46 minutes ago]

Thu, 14 Aug 2014 16:21:22 GMT

Am 14.08.2014 16:12, schrieb Jaime Vives Piqueres:

>    That worked, thanks... I was trying to test the persistent variables
> with an animation of my bullet physics car, and it worked great: making
> the big meshes persistent, I've reduced the frame render times from
> 10-11s to 2-3s! So, the 11h render should be ready now in just 3h.

Hey, that's cool :-)

[Jaime Vives Piqueres] Re: Error compiling UberPOV master [4260 days 1 hour and 56 minutes ago]

Thu, 14 Aug 2014 14:12:09 GMT

El 14/08/14 a las #4, clipka escribiÃ³:
> As a quick fix, please remove the "SSE2_INCLUDED" from that line.
>

   That worked, thanks... I was trying to test the persistent variables
with an animation of my bullet physics car, and it worked great: making
the big meshes persistent, I've reduced the frame render times from
10-11s to 2-3s! So, the 11h render should be ready now in just 3h. Many
thanks for that patch!!!

--
Jaime

[clipka] Re: Error compiling UberPOV master [4260 days 3 hours and 25 minutes ago]

Thu, 14 Aug 2014 12:42:54 GMT

Am 14.08.2014 12:22, schrieb Jaime Vives Piqueres:
> Hi:
>
>    Just downloaded the zip and tried to compile using:
>
> ../configure COMPILED_BY="JVP <jai### [at] ignoranciaorg>"
> --disable-io-restrictions --without-libtiff NON_REDISTRIBUTABLE_BUILD=yes
>
>    on Ubuntu 12.04 , but got the following error:
>
> backend/povray.cpp:301:110: error: expected â€˜)â€™
before â€˜SSE2_INCLUDEDâ€™
>
>    POV-Ray stable compiles fine here with the same configure call...
>
>    Any ideas? Regards,

As a quick fix, please remove the "SSE2_INCLUDED" from that line.

[Jaime Vives Piqueres] Error compiling UberPOV master [4260 days 5 hours and 45 minutes ago]

Thu, 14 Aug 2014 10:22:45 GMT

Hi:

   Just downloaded the zip and tried to compile using:

./configure COMPILED_BY="JVP <jai### [at] ignoranciaorg>" 
--disable-io-restrictions --without-libtiff NON_REDISTRIBUTABLE_BUILD=yes

   on Ubuntu 12.04 , but got the following error:

backend/povray.cpp:301:110: error: expected â€˜)â€™
before â€˜SSE2_INCLUDEDâ€™

   POV-Ray stable compiles fine here with the same configure call...

   Any ideas? Regards,

--
jaime

[scott] Re: UberPOV v1.37.0.0-beta.6 released [4261 days 9 hours and 11 minutes ago]

Wed, 13 Aug 2014 06:57:04 GMT

>> I found under some conditions you get a visible pattern to the noise
>> when doing a low quality "preview" render with no_cache. It's almost as
>> if the random number generator is seeded off the pixel coordinate or
>> something? Is this possible or am I seeing patterns where none exist?
>>
>
> A simple way to check that: Launch a 2 or 3 frames animation with no
> changes between the frames.
> If there is a repeatable pattern, the images will show the same pattern.
> If the pattern is just random noise, it will change from frame to frame.

OK it's the same every frame, I'll post an image in p.b.i.

[Alain] Re: UberPOV v1.37.0.0-beta.6 released [4261 days 21 hours and 50 minutes ago]

Tue, 12 Aug 2014 18:17:26 GMT

Le 14-08-11 06:24, scott a écrit :
>> Now with those fancy finish features recently shown off in
>> povray.binary.images.
>>
>> Also does stochastic global illumination now.
>
> I found under some conditions you get a visible pattern to the noise
> when doing a low quality "preview" render with no_cache. It's almost as
> if the random number generator is seeded off the pixel coordinate or
> something? Is this possible or am I seeing patterns where none exist?
>

A simple way to check that: Launch a 2 or 3 frames animation with no 
changes between the frames.
If there is a repeatable pattern, the images will show the same pattern. 
If the pattern is just random noise, it will change from frame to frame.


Alain

[scott] Re: UberPOV v1.37.0.0-beta.6 released [4263 days 5 hours and 43 minutes ago]

Mon, 11 Aug 2014 10:24:23 GMT

> Now with those fancy finish features recently shown off in
> povray.binary.images.
>
> Also does stochastic global illumination now.

I found under some conditions you get a visible pattern to the noise 
when doing a low quality "preview" render with no_cache. It's almost as 
if the random number generator is seeded off the pixel coordinate or 
something? Is this possible or am I seeing patterns where none exist?

[clipka] Re: UberPOV v1.37.0.0-beta.6 released [4270 days 6 hours and 53 minutes ago]

Mon, 4 Aug 2014 09:14:38 GMT

Am 03.08.2014 20:59, schrieb James Holsenback:
> On 07/26/2014 01:57 PM, clipka wrote:
>> Am 26.07.2014 14:44, schrieb James Holsenback:
>>> On 07/24/2014 12:01 AM, clipka wrote:
>>>> Also does stochastic global illumination now.
>>>
>>> are there any other parameters (besides count and brightness) that work
>>> in this mode? changes.txt says most don't ... just curious
>>
>> Just browsed the list of all the settings; The following should still
>> have an effect:
>>
>>      brightness FLOAT
>>      count FLOAT
>>      gray_threshold FLOAT
>>      recursion_limit INT
>>      adc_bailout FLOAT
>>      normal BOOL
>>      media BOOL
>>      subsurface BOOL
>>      brilliance BOOL
>>
>> All others are just concerned with sample caching.
>>
>
> what would be the best parameter to use if I'm seeing artifact in
> corners (shadow of an object hits floor and wall and it's darker where
> the wall and floor meet) ... I want to say count, but I also have an
> emission object, so I'm wondering if adc_bailout might also come into play

No, with no_cache the count parameter is less about quality and more 
about render speed.

But I'd have to see the artifacts to think of a reason why they'd be 
there and how they could be avoided.

[James Holsenback] Re: UberPOV v1.37.0.0-beta.6 released [4270 days 21 hours and 8 minutes ago]

Sun, 3 Aug 2014 18:59:27 GMT

On 07/26/2014 01:57 PM, clipka wrote:
> Am 26.07.2014 14:44, schrieb James Holsenback:
>> On 07/24/2014 12:01 AM, clipka wrote:
>>> Also does stochastic global illumination now.
>>
>> are there any other parameters (besides count and brightness) that work
>> in this mode? changes.txt says most don't ... just curious
>
> Just browsed the list of all the settings; The following should still
> have an effect:
>
>      brightness FLOAT
>      count FLOAT
>      gray_threshold FLOAT
>      recursion_limit INT
>      adc_bailout FLOAT
>      normal BOOL
>      media BOOL
>      subsurface BOOL
>      brilliance BOOL
>
> All others are just concerned with sample caching.
>

what would be the best parameter to use if I'm seeing artifact in 
corners (shadow of an object hits floor and wall and it's darker where 
the wall and floor meet) ... I want to say count, but I also have an 
emission object, so I'm wondering if adc_bailout might also come into play

[FractRacer] Re: UberPOV v1.37.0.0-beta.6 released [4276 days 3 hours and 3 minutes ago]

Tue, 29 Jul 2014 13:04:30 GMT

Le 29/07/2014 14:43, FractRacer a écrit :
> It seems that nothing appear when a scene like this is rendered. The
> image is black if version is 3.7; rather unofficial patch 3.7;
>
> version 3.7;
> //#version unofficial patch 3.7;
>

Oops, I have missed the # before the version directive, it is why all is 
black (even with pov3.7). I have an parse message which says there is no 
objects in scene.

Lionel


---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.com

[FractRacer] Re: UberPOV v1.37.0.0-beta.6 released [4276 days 3 hours and 24 minutes ago]

Tue, 29 Jul 2014 12:43:48 GMT

Le 24/07/2014 06:01, clipka a écrit :
> Now with those fancy finish features recently shown off in
> povray.binary.images.
>
> Also does stochastic global illumination now.
>
>
> Get the Windows binaries or cross-platform source code here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.6

It seems that nothing appear when a scene like this is rendered. The 
image is black if version is 3.7; rather unofficial patch 3.7;

version 3.7;
//#version unofficial patch 3.7;

camera {
	location <15, 15, -15>
	look_at <0, 0, 0>
	angle 90
}

//background {color 0.5}


plane {
	y,-1
	pigment {color 0.25}
}

box {
	<-1.00, 0.00, -1.00>,< 1.00, 2.00, 1.00>
	texture {
		pigment{ color rgb<1.00, 1.00, 1.00>}
		finish { phong 1 reflection{ 0.00 metallic 0.00} }
	}
}

light_source { <20, 20, -20> color rgb 1 }

-- 
Do not judge my words, judge my actions.

---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce
que la protection avast! Antivirus est active.
http://www.avast.com

[clipka] Re: UberPOV stand-alone installer released [4277 days 4 hours and 23 minutes ago]

Mon, 28 Jul 2014 11:44:32 GMT

Am 28.07.2014 11:03, schrieb Friedrich:

> Am 26.07.2014 10:31, schrieb clipka:> UberPOV now has its own installer!
> Yay!
>  >
>  >...
>  >
>  > I'd be happy if some people would give the ".stalone" installer
>  > a test drive; ...
>
> Thank you very much! Great work!

Thanks. Love to hear that.

> I'm missing: an example for blink feature!

Looks like I goofed that one. You should be able to find one called 
"blink.pov" in the GitHub repo, right here:

https://github.com/UberPOV/UberPOV/tree/master/distribution/scenes/uberpov

Apparently the revision I built was not the one tagged 
"v1.37.0.0-beta.7", but the commit right before that (83d4165). 
Fortunately the missing sample scene is the only thing that's different 
between the two.

> By the way:
> I have corrected the include file "shapes3.inc"
> (elimated a transformation error in one shape!)
> I append it to this email.
>
> It would be nice if you can integrate this corrected version
> of the "shapes3.inc" in your UberPOV now, so it will have
> the chance to be updated also in an update of the official POV-Ray 3.7.0
> (... hope within the current century ;-) ).

I won't do that. UberPOV is intended to be a collection of patches, not 
of fixes. If it's broken in POV-Ray, that's where it should be fixed.

I'll therefore submit it to the POV-Ray repo.

If you intend to provide more fixes, samples, templates etc., feel free 
to create your own fork of the POV-Ray repo on GitHub, make changes on 
that fork as you see fit, and then submit those changes as a pull 
request. Once you have gone through setting up that fork and installing 
a Git client (I'd recommend Atlassian SourceTree), I think that's the 
easiest procedure for all involved.

[Thomas de Groot] Re: UberPOV stand-alone installer released [4277 days 4 hours and 53 minutes ago]

Mon, 28 Jul 2014 11:15:10 GMT

On 28-7-2014 11:03, Friedrich wrote:
> I'm missing: an example for blink feature!
> I tried to invoke the motion blur effect but ... failed :-(

Try this:

//With a James Holsenback metallic texture:
#macro MetalMat (Color)
material {
   texture {
     pigment {srgb Color*1.5}
     finish {
       brilliance 4
       diffuse 0
       metallic
       specular 0.80
       roughness 1/40
       reflection {srgb Color roughness 1e-5}
     }
   }
   interior {
     ior 1.5
   }
}
#end

//the calls: MetalMat (<0.65, 0.15, 0.25>) MetalMat (<0.5, 0.65, 0.25>) 
MetalMat (<0.25, 0.5, 0.65>)
#local Ovus =
ovus {
   1.00, 0.65 // base_radius, top_radius  with: top_radius< base_radius!
   translate 0.5*y
   scale 0.5
}

#local DeltaT = 0.1;

union {
   #for (T, 0.0, 1-DeltaT, DeltaT)
   object {Ovus rotate <0, 0, 2/T> blink 0, T+DeltaT}
   #end
   #for (T, 0.0, 1-DeltaT, DeltaT)
   object {Ovus rotate <0, 0, -2/T> blink 0, T+DeltaT}
   #end
   translate <-1.00, 0.0, -1>
   MetalMat (<0.65, 0.15, 0.25>)
}
//-------------------------------------------------------------------------

union {
#for (T, 0.0, 1-DeltaT, DeltaT)
   sphere {
     <T, 0.25, -1.2>, 0.25
     blink 0, T+DeltaT
   }
#end
     MetalMat (<0.5, 0.65, 0.25>)
}


Thomas

[Friedrich] Re: UberPOV stand-alone installer released [4277 days 7 hours and 4 minutes ago]

Mon, 28 Jul 2014 09:03:21 GMT

Am 26.07.2014 10:31, schrieb clipka:> UberPOV now has its own installer! 
Yay!
 >
 >...
 >
 > I'd be happy if some people would give the ".stalone" installer
 > a test drive; ...

Thank you very much! Great work!
After copying the missing editor dlls for POV-Ray - no problems.


Tested your example files of the new features!
Every thing seems to be alright!

I'm missing: an example for blink feature!
I tried to invoke the motion blur effect but ... failed :-(


By the way:
I have corrected the include file "shapes3.inc"
(elimated a transformation error in one shape!)
I append it to this email.

It would be nice if you can integrate this corrected version
of the "shapes3.inc" in your UberPOV now, so it will have
the chance to be updated also in an update of the official POV-Ray 3.7.0
(... hope within the current century ;-) ).

Friedrich

[Thomas de Groot] Re: UberPOV stand-alone installer released [4278 days 9 hours and 4 minutes ago]

Sun, 27 Jul 2014 07:04:14 GMT

On 26-7-2014 19:46, clipka wrote:
> No; if you have an existing POV-Ray installation, it turns out you'll
> have to copy the files manually.

no problem.

>
> It also turns out that the editor - being a genuine POV-Ray component -
> still uses POV-Ray's part of the registry; I guess I'll have to roll my
> own version of that as well, but I'm somewhat wary of the legal side of it.
>

Understood.

Thomas

[clipka] Re: UberPOV v1.37.0.0-beta.6 released [4278 days 22 hours and 10 minutes ago]

Sat, 26 Jul 2014 17:57:43 GMT

Am 26.07.2014 14:44, schrieb James Holsenback:
> On 07/24/2014 12:01 AM, clipka wrote:
>> Also does stochastic global illumination now.
>
> are there any other parameters (besides count and brightness) that work
> in this mode? changes.txt says most don't ... just curious

Just browsed the list of all the settings; The following should still 
have an effect:

     brightness FLOAT
     count FLOAT
     gray_threshold FLOAT
     recursion_limit INT
     adc_bailout FLOAT
     normal BOOL
     media BOOL
     subsurface BOOL
     brilliance BOOL

All others are just concerned with sample caching.

[clipka] Re: UberPOV stand-alone installer released [4278 days 22 hours and 21 minutes ago]

Sat, 26 Jul 2014 17:47:08 GMT

Am 26.07.2014 14:33, schrieb Thomas de Groot:
> the .stalone version works flawlessly (see image in p.b.i.). Only thing
> I have not been able to do is install the editor. Do I have to run the
> installer inside the UberPOV folder maybe?

No; if you have an existing POV-Ray installation, it turns out you'll 
have to copy the files manually.

It also turns out that the editor - being a genuine POV-Ray component - 
still uses POV-Ray's part of the registry; I guess I'll have to roll my 
own version of that as well, but I'm somewhat wary of the legal side of it.

[James Holsenback] Re: UberPOV v1.37.0.0-beta.6 released [4279 days 3 hours and 19 minutes ago]

Sat, 26 Jul 2014 12:48:26 GMT

On 07/24/2014 12:01 AM, clipka wrote:
> Also does stochastic global illumination now.

are there any parameters (besides count and brightness) that work in 
this mode? changes.txt says most don't ... just curious

[James Holsenback] Re: UberPOV v1.37.0.0-beta.6 released [4279 days 3 hours and 23 minutes ago]

Sat, 26 Jul 2014 12:44:38 GMT

On 07/24/2014 12:01 AM, clipka wrote:
> Also does stochastic global illumination now.

are there any other parameters (besides count and brightness) that work 
in this mode? changes.txt says most don't ... just curious

[Thomas de Groot] Re: UberPOV stand-alone installer released [4279 days 3 hours and 34 minutes ago]

Sat, 26 Jul 2014 12:33:28 GMT

the .stalone version works flawlessly (see image in p.b.i.). Only thing 
I have not been able to do is install the editor. Do I have to run the 
installer inside the UberPOV folder maybe?

Thomas

[clipka] UberPOV stand-alone installer released [4279 days 7 hours and 36 minutes ago]

Sat, 26 Jul 2014 08:31:50 GMT

UberPOV now has its own installer! Yay!

 From now on, UberPOV will come in two flavors:

- The classic version (e.g. 1.37.0.0-beta.7) that comes as a raw .exe to 
be dropped into an existing installation, and shares POV-Ray's entire 
ecosystem of sample scenes, include files, settings and what-have-you.

- A ".stalone" version (e.g. 1.37.0.0-beta.7.stalone) coming as a 
full-fledged installer, to set up its own ecosystem and neither require, 
nor mess with, any existing POV-Ray installation.

I'd be happy if some people would give the ".stalone" installer a test 
drive; you can download it from here:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.7

(Aside from being available as a stand-alone version, beta.7 should be 
virtually identical to beta.6.)

[clipka] Re: Is anyone working on a distributed / stochas... [4280 days 22 hours and 14 minutes ago]

Thu, 24 Jul 2014 17:53:24 GMT

Am 24.07.2014 17:58, schrieb Nekar Xenos:
> On Wed, 23 Jul 2014 21:52:32 +0200, clipka <ano### [at] anonymousorg> wrote:
>
>
>> (Actually it's not /that/ much of a coincidence: As a first approach
>> at "replacing" radiosity I plan to actually just keep using it but not
>> cache the results (plus make sure that the secondary rays shot are
>> different each time); and as I want UberPOV to fully support
>> non-default brilliance settings, I figured that I might just as well
>> add that to POV-Ray's radiosity first... And then one thing led to
>> another, and I found myself adding all those fancy finish improvements
>> that had been on my agenda for so long...)
>>
>
> You're our hero :)

Thanks. Sometimes I am. ;-)

[Nekar Xenos] Re: Is anyone working on a distributed / stochas... [4281 days and 9 minutes ago]

Thu, 24 Jul 2014 15:58:37 GMT

On Wed, 23 Jul 2014 21:52:32 +0200, clipka <ano### [at] anonymousorg> wrote:


> (Actually it's not /that/ much of a coincidence: As a first approach at  
> "replacing" radiosity I plan to actually just keep using it but not  
> cache the results (plus make sure that the secondary rays shot are  
> different each time); and as I want UberPOV to fully support non-default  
> brilliance settings, I figured that I might just as well add that to  
> POV-Ray's radiosity first... And then one thing led to another, and I  
> found myself adding all those fancy finish improvements that had been on  
> my agenda for so long...)
>

You're our hero :)

-- 
-Nekar Xenos-

[clipka] UberPOV v1.37.0.0-beta.6 released [4281 days 12 hours and 7 minutes ago]

Thu, 24 Jul 2014 04:01:09 GMT

Now with those fancy finish features recently shown off in 
povray.binary.images.

Also does stochastic global illumination now.


Get the Windows binaries or cross-platform source code here:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.6

[Alain] Re: Is anyone working on a distributed / stochas... [4281 days 18 hours and 46 minutes ago]

Wed, 23 Jul 2014 21:21:57 GMT

Le 14-07-23 15:52, clipka a écrit :

> (Actually it's not /that/ much of a coincidence: As a first approach at
> "replacing" radiosity I plan to actually just keep using it but not
> cache the results (plus make sure that the secondary rays shot are
> different each time); and as I want UberPOV to fully support non-default
> brilliance settings, I figured that I might just as well add that to
> POV-Ray's radiosity first... And then one thing led to another, and I
> found myself adding all those fancy finish improvements that had been on
> my agenda for so long...)
>

And you did a marvelous job at that. Tank you very much :)

[clipka] Re: Is anyone working on a distributed / stochas... [4281 days 20 hours and 15 minutes ago]

Wed, 23 Jul 2014 19:52:39 GMT

Am 23.07.2014 20:18, schrieb Nekar Xenos:

> What I would like to see with radiosity is a system that distinguishes
> between different materials. Smooth shiny materials should have a
> smaller cone of scattering than cement which should have a very wide
> angle of scattering.

Well... no, not really. In smooth shiny materials, the primary direction 
of the cone of scattering virtually always depends on the angle of the 
incoming light, approaching classic specular reflection as the object 
gets even smoother.

To model such cases, POV-Ray's radiosity approach is inherently 
unsuited, because the sample information needs to be very 
memory-efficient and thus quite limited - POV-Ray only stores a single 
weighted average of all the light coming in, so any information about 
the direction of the incoming light is lost entirely.

What really kicks ass for smooth shiny (but not perfectly polished) 
materials is blurred reflections; with a strong blur it can even give a 
subtle edge to comparatively dull materials


That doesn't mean your idea would be all nonsense though - see the stuff 
I happen to have just shown off in the "Brilliant Spheres" thread on 
povray.binary.images ;-)

(Actually it's not /that/ much of a coincidence: As a first approach at 
"replacing" radiosity I plan to actually just keep using it but not 
cache the results (plus make sure that the secondary rays shot are 
different each time); and as I want UberPOV to fully support non-default 
brilliance settings, I figured that I might just as well add that to 
POV-Ray's radiosity first... And then one thing led to another, and I 
found myself adding all those fancy finish improvements that had been on 
my agenda for so long...)

[Nekar Xenos] Re: Is anyone working on a distributed / stochas... [4281 days 21 hours and 49 minutes ago]

Wed, 23 Jul 2014 18:18:44 GMT

On Sun, 20 Jul 2014 20:45:27 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 20.07.2014 19:44, schrieb Nekar Xenos:
>>
>> Is anyone working on a distributed / stochastic / Monte  
>> Carloray-tracing patch for 3.7?
>
> Distributed raytracing patch: Planned for official POV-Ray; don't hold  
> your breath though.
>
> Stochastic / Monte Carlo raytracing patch: Maybe UberPOV  
> (https://github.com/UberPOV/UberPOV) already offers what you're looking  
> for; it already uses stochastic rendering for various features. If  
> stochastic global illumination is what you're after, just drop me a note  
> and I'll make that happen as well.
>

What I would like to see with radiosity is a system that distinguishes  
between different materials. Smooth shiny materials should have a smaller  
cone of scattering than cement which should have a very wide angle of  
scattering.

-- 
-Nekar Xenos-

[Nekar Xenos] Re: Is anyone working on a distributed / stochas... [4281 days 21 hours and 55 minutes ago]

Wed, 23 Jul 2014 18:12:54 GMT

On Tue, 22 Jul 2014 00:53:47 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 21.07.2014 21:12, schrieb Nekar Xenos:
>> On Sun, 20 Jul 2014 20:45:27 +0200, clipka <ano### [at] anonymousorg>  
>> wrote:
>>
>>> Am 20.07.2014 19:44, schrieb Nekar Xenos:
>>>>
>>>> Is anyone working on a distributed / stochastic / Monte
>>>> Carloray-tracing patch for 3.7?
>>>
>>> Distributed raytracing patch: Planned for official POV-Ray; don't hold
>>> your breath though.
>>>
>>> Stochastic / Monte Carlo raytracing patch: Maybe UberPOV
>>> (https://github.com/UberPOV/UberPOV) already offers what you're
>>> looking for; it already uses stochastic rendering for various
>>> features. If stochastic global illumination is what you're after, just
>>> drop me a note and I'll make that happen as well.
>>>
>>
>> I'm not 100% sure what the correct term is, the Wikipedia entry was a
>> bit confusing. I can describe it as following the ray from the light
>> source to the screen. Just like MCPov, only with all of the 3.7  
>> features.
>
> Hmm, there's definitely some misunderstanding going on here.
>
> "Following the ray from the light source to the screen" is /forward  
> raytracing/, as opposed to following the ray from the screen to the  
> object surface and ultimately to the light source, aka /backward  
> raytracing/. The latter is the classic approach, and the one used by  
> POV-Ray.
>
> MCPov also uses /backward/ raytracing like POV-Ray.
>
I don't know why I thought MCPov used forward ray-tracing. I think it was  
probably because of the slow rendering and good results after waiting a  
long time ;)

> /Stochastic/ raytracing can be done with both approaches (I guess it is  
> the only way to do forward raytracing, but it is also a way to do  
> backward raytracing), or even with combinations of the two, such as  
> bidirectional raytracing, Metropolis Light Transport or some such.
>
>
> So let's forget about the technical terms, and start at the other end:
>
> What is it about MCPov that you actually want?
>
> Blurred reflections? Definitely go for UberPOV, as it has them. Yay!
>
> Blurred refractions? Not supported by UberPOV yet, but shouldn't be too  
> difficult to add once I decide on a nice syntax.

That would be useful.
>
> A less artifact-prone replacement for the effect that official POV-Ray  
> uses radiosity for (so-called Global Illumination)? Raise your hand, and  
> I'll make it happen in UberPOV.
>

*raises hand*

> Render over and over again while you sit and watch, until you're happy  
> with the result? Not supported in UberPOV yet; it's on the agenda, but  
> may require quite some intrusion into the POV-Ray architecture. What  
> UberPOV does already support, however, is an "anti-aliasing" mode (or,  
> more to the point, an oversampling mode) that allows you to specify what  
> quality you'd be happy with, and UberPOV will do the  
> rendering-over-and-over-again in the background until the quality  
> criteria are met.
>

Yes, please :)
>
> As a rule of thumb, if MCPov has it, it is also planned (if not already  
> implemented) for UberPOV.
>
Whoo-hoo!



-- 
-Nekar Xenos-

[Nekar Xenos] Re: Is anyone working on a distributed / stochas... [4281 days 22 hours and 2 minutes ago]

Wed, 23 Jul 2014 18:05:38 GMT

On Tue, 22 Jul 2014 14:26:28 +0200, clipka <ano### [at] anonymousorg> wrote:

> Two other things that had always bothered me about MCPov is that it  
> doesn't allow the use of classic light source (which would be far less  
> noisy and hence much faster than using bright spheres), and that it has  
> a factor-2 error in diffuse computations that make it necessary to use  
> different finish settings. Both make it excessively difficult to create  
> scenes that render essentially identical (except for artifacts or noise)  
> in both POV-Ray and MCPov. Needless to say that UberPOV is intended to  
> do a better job in that respect.
>

And there was also a problem with media. I hope UberPov will be able to do  
what MCPov did and still be able to render different types of media  
correctly.

-- 
-Nekar Xenos-

[scott] Re: Is anyone working on a distributed / stochas... [4283 days 2 hours and 56 minutes ago]

Tue, 22 Jul 2014 13:11:57 GMT

> Two other things that had always bothered me about MCPov is that it
> doesn't allow the use of classic light source (which would be far less
> noisy and hence much faster than using bright spheres), and that it has
> a factor-2 error in diffuse computations that make it necessary to use
> different finish settings. Both make it excessively difficult to create
> scenes that render essentially identical (except for artifacts or noise)
> in both POV-Ray and MCPov. Needless to say that UberPOV is intended to
> do a better job in that respect.

Yes, I have a few macros so that scenes can work in both POV and MCPov 
but it's a messy solution (and obviously I can't use any 3.7 features).

[clipka] Re: Is anyone working on a distributed / stochas... [4283 days 3 hours and 41 minutes ago]

Tue, 22 Jul 2014 12:26:33 GMT

Am 22.07.2014 09:11, schrieb scott:
>> A less artifact-prone replacement for the effect that official POV-Ray
>> uses radiosity for (so-called Global Illumination)? Raise your hand, and
>> I'll make it happen in UberPOV.
>
> I don't know what you have in mind for this, if it's not the render over
> and over again approach?

Essentially that, yes.

At the moment, for Global Illumination UberPOV still uses the same 
approach as POV-Ray: On an object's surface it chooses some points more 
or less at random, for which it computes indirect illumination with high 
precision(*), and caches this information; for any points in between, 
indirect illumination is interpolated from nearby cached samples. This 
interpolation can lead to systematic artifacts that are difficult to get 
rid of - obviously it's not enough to just sample the image over and 
over again with the same set of cached samples.

(*) Computation of indirect illumination is done simply by shooting a 
number of secondary rays, and see what light might come from other 
objects present there; the more rays are shot, the more precise the 
result will be.

To avoid the typical POV-Ray radiosity artifacts, MCPov (re-)computes 
indirect illumination for each and every point on an object's surface, 
and doesn't cache the results at all. Usually this is done with a 
comparatively low precision, which also leads to artifacts; however, 
they manifest as random noise that can be reduced by oversampling pixels 
over and over again.

>> Render over and over again while you sit and watch, until you're happy
>> with the result? Not supported in UberPOV yet; it's on the agenda, but
>> may require quite some intrusion into the POV-Ray architecture. What
>> UberPOV does already support, however, is an "anti-aliasing" mode (or,
>> more to the point, an oversampling mode) that allows you to specify what
>> quality you'd be happy with, and UberPOV will do the
>> rendering-over-and-over-again in the background until the quality
>> criteria are met.
>
> This seems like a better approach, as with MCPov you're often left
> re-rendering the entire image waiting for just a small dark area to
> smooth out.

It's not all that bad; MCPov does spend more time on areas of the image 
that prove to really need the additional work.

> So if you implement the less artefact-prone GI and combine it with the
> per-pixel oversampling it should be something better than MCPov? Sounds
> good to me! Hand firmly raised!

I'm not sure if it that'll suffice to indeed be better than MCPov; time 
will tell. A definitive advantage will be the full support for 
multithreading.

Two other things that had always bothered me about MCPov is that it 
doesn't allow the use of classic light source (which would be far less 
noisy and hence much faster than using bright spheres), and that it has 
a factor-2 error in diffuse computations that make it necessary to use 
different finish settings. Both make it excessively difficult to create 
scenes that render essentially identical (except for artifacts or noise) 
in both POV-Ray and MCPov. Needless to say that UberPOV is intended to 
do a better job in that respect.

[scott] Re: Is anyone working on a distributed / stochas... [4283 days 8 hours and 56 minutes ago]

Tue, 22 Jul 2014 07:11:32 GMT

> A less artifact-prone replacement for the effect that official POV-Ray
> uses radiosity for (so-called Global Illumination)? Raise your hand, and
> I'll make it happen in UberPOV.

I don't know what you have in mind for this, if it's not the render over 
and over again approach?

> Render over and over again while you sit and watch, until you're happy
> with the result? Not supported in UberPOV yet; it's on the agenda, but
> may require quite some intrusion into the POV-Ray architecture. What
> UberPOV does already support, however, is an "anti-aliasing" mode (or,
> more to the point, an oversampling mode) that allows you to specify what
> quality you'd be happy with, and UberPOV will do the
> rendering-over-and-over-again in the background until the quality
> criteria are met.

This seems like a better approach, as with MCPov you're often left 
re-rendering the entire image waiting for just a small dark area to 
smooth out.

So if you implement the less artefact-prone GI and combine it with the 
per-pixel oversampling it should be something better than MCPov? Sounds 
good to me! Hand firmly raised!

[clipka] Re: Is anyone working on a distributed / stochas... [4283 days 17 hours and 14 minutes ago]

Mon, 21 Jul 2014 22:53:51 GMT

Am 21.07.2014 21:12, schrieb Nekar Xenos:
> On Sun, 20 Jul 2014 20:45:27 +0200, clipka <ano### [at] anonymousorg> wrote:
>
>> Am 20.07.2014 19:44, schrieb Nekar Xenos:
>>>
>>> Is anyone working on a distributed / stochastic / Monte
>>> Carloray-tracing patch for 3.7?
>>
>> Distributed raytracing patch: Planned for official POV-Ray; don't hold
>> your breath though.
>>
>> Stochastic / Monte Carlo raytracing patch: Maybe UberPOV
>> (https://github.com/UberPOV/UberPOV) already offers what you're
>> looking for; it already uses stochastic rendering for various
>> features. If stochastic global illumination is what you're after, just
>> drop me a note and I'll make that happen as well.
>>
>
> I'm not 100% sure what the correct term is, the Wikipedia entry was a
> bit confusing. I can describe it as following the ray from the light
> source to the screen. Just like MCPov, only with all of the 3.7 features.

Hmm, there's definitely some misunderstanding going on here.

"Following the ray from the light source to the screen" is /forward 
raytracing/, as opposed to following the ray from the screen to the 
object surface and ultimately to the light source, aka /backward 
raytracing/. The latter is the classic approach, and the one used by 
POV-Ray.

MCPov also uses /backward/ raytracing like POV-Ray.

/Stochastic/ raytracing can be done with both approaches (I guess it is 
the only way to do forward raytracing, but it is also a way to do 
backward raytracing), or even with combinations of the two, such as 
bidirectional raytracing, Metropolis Light Transport or some such.

So let's forget about the technical terms, and start at the other end:

What is it about MCPov that you actually want?

Blurred reflections? Definitely go for UberPOV, as it has them. Yay!

Blurred refractions? Not supported by UberPOV yet, but shouldn't be too 
difficult to add once I decide on a nice syntax.

A less artifact-prone replacement for the effect that official POV-Ray 
uses radiosity for (so-called Global Illumination)? Raise your hand, and 
I'll make it happen in UberPOV.

Render over and over again while you sit and watch, until you're happy 
with the result? Not supported in UberPOV yet; it's on the agenda, but 
may require quite some intrusion into the POV-Ray architecture. What 
UberPOV does already support, however, is an "anti-aliasing" mode (or, 
more to the point, an oversampling mode) that allows you to specify what 
quality you'd be happy with, and UberPOV will do the 
rendering-over-and-over-again in the background until the quality 
criteria are met.

As a rule of thumb, if MCPov has it, it is also planned (if not already 
implemented) for UberPOV.

[Nekar Xenos] Re: Is anyone working on a distributed / stochas... [4283 days 20 hours and 56 minutes ago]

Mon, 21 Jul 2014 19:12:14 GMT

On Sun, 20 Jul 2014 20:45:27 +0200, clipka <ano### [at] anonymousorg> wrote:

> Am 20.07.2014 19:44, schrieb Nekar Xenos:
>>
>> Is anyone working on a distributed / stochastic / Monte  
>> Carloray-tracing patch for 3.7?
>
> Distributed raytracing patch: Planned for official POV-Ray; don't hold  
> your breath though.
>
> Stochastic / Monte Carlo raytracing patch: Maybe UberPOV  
> (https://github.com/UberPOV/UberPOV) already offers what you're looking  
> for; it already uses stochastic rendering for various features. If  
> stochastic global illumination is what you're after, just drop me a note  
> and I'll make that happen as well.
>

I'm not 100% sure what the correct term is, the Wikipedia entry was a bit  
confusing. I can describe it as following the ray from the light source to  
the screen. Just like MCPov, only with all of the 3.7 features.

-- 
-Nekar Xenos-

[clipka] Re: Is anyone working on a distributed / stochas... [4284 days 21 hours and 22 minutes ago]

Sun, 20 Jul 2014 18:45:29 GMT

Am 20.07.2014 19:44, schrieb Nekar Xenos:
>
> Is anyone working on a distributed / stochastic / Monte Carloray-tracing patch for
3.7?

Distributed raytracing patch: Planned for official POV-Ray; don't hold 
your breath though.

Stochastic / Monte Carlo raytracing patch: Maybe UberPOV 
(https://github.com/UberPOV/UberPOV) already offers what you're looking 
for; it already uses stochastic rendering for various features. If 
stochastic global illumination is what you're after, just drop me a note 
and I'll make that happen as well.

[Nekar Xenos] Is anyone working on a distributed / stochastic ... [4284 days 22 hours and 23 minutes ago]

Sun, 20 Jul 2014 17:44:19 GMT

-- 
-Nekar Xenos-

[Christian Froeschlin] Re: Patch or Unofficial Version with Persistent ... [4308 days 17 hours and 42 minutes ago]

Thu, 26 Jun 2014 22:25:39 GMT

On 27.05.2014 21:14, clipka wrote:

> You are hereby sentenced to have your code stolen from you, mangled, and
> integrated into UberPOV :-P

Hey, very cool! After all these years I finally contributed something ;)

The issue popped up now and then in the newsgroups so I'm sure a few
animators will be made happy once they discover this. It's been too long
since I rendered anything myself but I'll definitely have to check out
UberPOV at some point.

[kurtz le pirate] Re: Update POV-Ray 3.7 unofficial for Mac GUI (r3) [4334 days 7 hours and 1 minute ago]

Sun, 1 Jun 2014 09:06:43 GMT

Le 31/05/2014 19:01, Yvo Smellenbergh a écrit :
> An update for POV-Ray 3.7 unofficial GUI version for Mac is available at:
> http://megapov.inetart.net/povrayunofficial_mac/index.html#Mac
>
> What is new in POVRay3_7_Unofficial r3:
> --------------------------------------------------------
> 1.  turned off "smart quotes" in the editor (bug in Mavericks)
> 2. insert menu sorts correctly and separator lines are used.
> 3. insert menu watches every directory for changes and updates accordingly
> 4. rearranged preview window code to improve speed
> 5. compiled with Xcode 5.1.1
> 6. pause/resume fixed
>
> UberPOV beta 5 will follow soon....
>
> Yvo


thanks again Yvo :)


just for elegance,(a little bit pernickety, i know), why not remove 
".txt" at the end of the items's menus ?




---
Kurtz le pirate
Compagnie de la Banquise

[Yvo Smellenbergh] Update POV-Ray 3.7 unofficial for Mac GUI (r3) [4334 days 23 hours and 6 minutes ago]

Sat, 31 May 2014 17:01:58 GMT

An update for POV-Ray 3.7 unofficial GUI version for Mac is available at:
http://megapov.inetart.net/povrayunofficial_mac/index.html#Mac

What is new in POVRay3_7_Unofficial r3:
--------------------------------------------------------
1.  turned off "smart quotes" in the editor (bug in Mavericks)
2. insert menu sorts correctly and separator lines are used.
3. insert menu watches every directory for changes and updates accordingly
4. rearranged preview window code to improve speed
5. compiled with Xcode 5.1.1
6. pause/resume fixed

UberPOV beta 5 will follow soon....

Yvo
-- 
-------------------------------------------------------------------------------------------


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[Yvo Smellenbergh] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4337 days 8 hours and 7 minutes ago]

Thu, 29 May 2014 08:00:37 GMT

Smart quotes are diabled by default but there seems to be a bug in 
Mavericks (settings in interface builder are ignored).
I will hard-code it in the next release to fix it.

Yvo

On 2014-05-28 21:14:12 +0000, Nathan said:

> Excellent, that worked great, thank you!
> 
> Still, POV, as a source code editor, should disable smart quotes by 
> default.  As
> is clear from the
> confusion in this thread (both the OP's and some of the replies), it's 
> a problem
> as is.
> 
> Thanks again.
> 
> Nathan
> 
> 
> yvo### [at] cancel_This_gmxnet (Yvo Smellenbergh) wrote:
>> You can turn if off globally:
>> http://derflounder.wordpress.com/2014/02/01/disabling-smart-quotes-in-ma
>> vericks/
>> 
>> Yvo


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


POV-Ray 3.7 unofficial: http://megapov.inetart.net/povrayunofficial_mac/
UberPOV Mac: http://megapov.inetart.net/uberpov_mac/index.html#Mac
MegaPOV: http://megapov.inetart.net
E-mail: yvo(DOT)s(AT)gmx.net

[Nathan] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4337 days 14 hours and 53 minutes ago]

Thu, 29 May 2014 01:15:01 GMT

Excellent, that worked great, thank you!

Still, POV, as a source code editor, should disable smart quotes by default.  As
is clear from the
confusion in this thread (both the OP's and some of the replies), it's a problem
as is.

Thanks again.

Nathan

yvo### [at] cancel_This_gmxnet (Yvo Smellenbergh) wrote:
> You can turn if off globally:
> http://derflounder.wordpress.com/2014/02/01/disabling-smart-quotes-in-ma
> vericks/
>
> Yvo
>

[clipka] UberPOV v1.37.0.0-beta.5 released [4337 days 19 hours and 48 minutes ago]

Wed, 28 May 2014 20:20:16 GMT

I guess you'll like it (as usual :D).

- Scenes with lots of fading light sources are now sped up, by computing 
such lights' influence only within a certain radius (depending on 
brightness, fade parameters and global adc_bailout by default).

- Animations can now be parsed much faster by storing data in a new 
flavor of variable that sticks around across frames. Kudos to Christian 
Froeschlin for this one.


Get the Windows binaries or the source code here:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.5

[Yvo Smellenbergh] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4337 days 23 hours and 5 minutes ago]

Wed, 28 May 2014 17:02:39 GMT

You can turn if off globally:
http://derflounder.wordpress.com/2014/02/01/disabling-smart-quotes-in-ma
vericks/

Yvo

Nathan <nca### [at] bentleyedu> wrote:

> I have the same problem.  The solution is simple but annoying:
> Right-click the editor, choose Substitutions, and uncheck Smart Quotes.
> The annoying thing is that you must do it every single time you open a
> file; the setting does not stick across launches of the app, or even from
> one window to the next.
> 
> This should be the default for all editor windows, and would fix the
> problem for everyone.  It's got to be a simple fix of just flipping a
> boolean flag on the standard editor widget in Xcode, I suspect.  Thanks
> for paying attention to it!
> 
> Nathan
> 
> 



-- ----------------------------------- MegaPOV at:
http://megapov.inetart.net MacMegaPOV at:
http://users.skynet.be/smellenbergh E-mail: yvo(DOT)s(AT)gmx.net

[clipka] Re: Patch or Unofficial Version with Persistent ... [4338 days 20 hours and 53 minutes ago]

Tue, 27 May 2014 19:14:23 GMT

Am 16.03.2014 19:15, schrieb Christian Froeschlin:

> I did hack something together for this based on 3.7b34 (back in
> 2009 I think) with the intent of creating a real patch after 3.7
> proper was released. Of course that turned out to be a lot of
> years in between and now mostly busy with other things.
>
> After your post I thought I might give it a shot but I actually got
> stuck already getting 3.7 release to compile (new computer, new OS,
> new Visual Studio version, changed build) and think I won't be
> focussing on this anytime soon.

...

> PS: Strictly speaking code changes based on beta version should not
> be published but the idea there is to prevent variants of unsupported
> and outdated versions making the rounds. I hope showing you one change
> I made in 2009 will not cause b34 to go rampant again :)

You surely are aware that this infringement cannot go unpunished, right? 
You are hereby sentenced to have your code stolen from you, mangled, and 
integrated into UberPOV :-P

See the following link for what is about to become of your idea:

https://github.com/UberPOV/UberPOV/tree/feature/persistent

[Nathan] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4339 days 1 hour and 43 minutes ago]

Tue, 27 May 2014 14:25:01 GMT

I have the same problem.  The solution is simple but annoying:  Right-click the
editor, choose Substitutions, and uncheck Smart Quotes.  The annoying thing is
that you must do it every single time you open a file; the setting does not
stick across launches of the app, or even from one window to the next.

This should be the default for all editor windows, and would fix the problem for
everyone.  It's got to be a simple fix of just flipping a boolean flag on the
standard editor widget in Xcode, I suspect.  Thanks for paying attention to it!

Nathan


yvo### [at] cancel_This_gmxnet (Yvo Smellenbergh) wrote:
> Can you e-mail me a screenshot after you typed:
> #include "colors.inc"
> And one after you saved and reopen the file in POV-Ray?
> And please send me the scene file also.
>
> POV-Ray unofficial uses the standard text input, I really have no idea
> right now what is going on.
> When I select US keyboard on my Mac Pro I have to press shift and a key
> near the return key to type a "-character. Totally different key
> compared to my Belgian keyboard but it works like expected.
>
> Yvo
>
>
> "David" <nomail@nomail> wrote:
>
> > > Can you please tell me what you have selected in "Input Sources" on the
> > > system Keyboard sytem preferences panel?
> >
> > Answer: U.S.
> >
> > Which stands for United States. Macbook Pro, Mavericks.
> >
> >
> > > I don't see why you get '"' and then
'Ã¢â€¢Â°' if you use the same key.
> > > And it only happens after saving the file?
> >
> > I open a New file from the File menu in the POVRary3_7_Unofficial software. I
> > then enter:
> >
> > #include "colors.incâ€°
> >
> > using the double quote key just  nest to the Resturn key on my Macbook Pro
> > keyboard.
> >
> > Then I save the file as demo.pov.
> >
> > Then I render, and I get this error:
> >
> > "/Users/davidarnold/Documents/temp/demo.pov"
> >  line 1
> > Parse Error: Illegal character in input file, value is d2.
> >
> > If I open a new file and save it as demo.pov, then enter the code
> >
> > #include "colors.incâ€°
> >
> > I get the same error.
> >
> > D.
> >
> >
> > yvo### [at] cancel_This_gmxnet (Yvo Smellenbergh) wrote:
> > > "David" <nomail@nomail> wrote:
> > >
> > > Can you please tell me what you have selected in "Input Sources" on the
> > > system Keyboard sytem preferences panel?
> > >
> > > I don't see why you get '"' and then
'Ã¢â€¢Â°' if you use the same key.
> > > And it only happens after saving the file?
> > > Nobody ever reported this...
> > >
> > > Yvo
> > >
> > > > I've installed povray3_7_unofficial on my Mavericks mac laptop. When I
> > > > open a new file and try to use the double quotes key on my keyboard, I
> > > > get:
> > > >
> > > > include "color.incÃ¢â€¢Â° include
"stones.incÃ¢â€¢Â° After saving the file as
> > > > demo.pos, when I try to render the file, I get this error message.
> > > >
> > > > "/Users/davidarnold/Documents/temp/demo.pov" line 1 Parse Error: Illegal
> > > > character in input file, value is d2.
> > > >
> > > > Now if I create this code in BBEdit, save the file as demo.pov, then open
> > > > it in POVRay3_7_Unofficial, it looks like this:
> > > >
> > > > include "colors.inc" include "stones.inc" And it renders just fine.
> > > >
> > > > Why isn't the quotation key on my Mavericks Mac keyboard giving me the
> > > > correct quotation symbol in POVRay3_7_Unofficial? I also tried using
> > > > Courier and Helvetica, to no avail or difference.
> > > >
> > > > David.
> > >
> > >
> > > -- ----------------------------------- MegaPOV at:
> > > http://megapov.inetart.net MacMegaPOV at:
> > > http://users.skynet.be/smellenbergh E-mail: yvo(DOT)s(AT)gmx.net
>
>
> --
> -----------------------------------
> MegaPOV at:  http://megapov.inetart.net
> MacMegaPOV at:  http://users.skynet.be/smellenbergh
> E-mail: yvo(DOT)s(AT)gmx.net

[Yvo Smellenbergh] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4359 days 23 hours and 50 minutes ago]

Tue, 6 May 2014 16:18:16 GMT

Can you e-mail me a screenshot after you typed:
#include "colors.inc"
And one after you saved and reopen the file in POV-Ray?
And please send me the scene file also.

POV-Ray unofficial uses the standard text input, I really have no idea
right now what is going on.
When I select US keyboard on my Mac Pro I have to press shift and a key
near the return key to type a "-character. Totally different key
compared to my Belgian keyboard but it works like expected.

Yvo


"David" <nomail@nomail> wrote:

> > Can you please tell me what you have selected in "Input Sources" on the
> > system Keyboard sytem preferences panel?
> 
> Answer: U.S.
> 
> Which stands for United States. Macbook Pro, Mavericks.
> 
> 
> > I don't see why you get '"' and then 'Ã¢â€¢Â°'
if you use the same key.
> > And it only happens after saving the file?
> 
> I open a New file from the File menu in the POVRary3_7_Unofficial software. I
> then enter:
> 
> #include "colors.incâ€°
> 
> using the double quote key just  nest to the Resturn key on my Macbook Pro
> keyboard.
> 
> Then I save the file as demo.pov.
> 
> Then I render, and I get this error:
> 
> "/Users/davidarnold/Documents/temp/demo.pov"
>  line 1
> Parse Error: Illegal character in input file, value is d2.
> 
> If I open a new file and save it as demo.pov, then enter the code
> 
> #include "colors.incâ€°
> 
> I get the same error.
> 
> D.
> 
> 
> yvo### [at] cancel_This_gmxnet (Yvo Smellenbergh) wrote:
> > "David" <nomail@nomail> wrote:
> >
> > Can you please tell me what you have selected in "Input Sources" on the
> > system Keyboard sytem preferences panel?
> >
> > I don't see why you get '"' and then 'Ã¢â€¢Â°'
if you use the same key.
> > And it only happens after saving the file?
> > Nobody ever reported this...
> >
> > Yvo
> >
> > > I've installed povray3_7_unofficial on my Mavericks mac laptop. When I
> > > open a new file and try to use the double quotes key on my keyboard, I
> > > get:
> > >
> > > include "color.incÃ¢â€¢Â° include
"stones.incÃ¢â€¢Â° After saving the file as
> > > demo.pos, when I try to render the file, I get this error message.
> > >
> > > "/Users/davidarnold/Documents/temp/demo.pov" line 1 Parse Error: Illegal
> > > character in input file, value is d2.
> > >
> > > Now if I create this code in BBEdit, save the file as demo.pov, then open
> > > it in POVRay3_7_Unofficial, it looks like this:
> > >
> > > include "colors.inc" include "stones.inc" And it renders just fine.
> > >
> > > Why isn't the quotation key on my Mavericks Mac keyboard giving me the
> > > correct quotation symbol in POVRay3_7_Unofficial? I also tried using
> > > Courier and Helvetica, to no avail or difference.
> > >
> > > David.
> >
> >
> > -- ----------------------------------- MegaPOV at:
> > http://megapov.inetart.net MacMegaPOV at:
> > http://users.skynet.be/smellenbergh E-mail: yvo(DOT)s(AT)gmx.net


-- 
-----------------------------------
MegaPOV at:  http://megapov.inetart.net
MacMegaPOV at:  http://users.skynet.be/smellenbergh
E-mail: yvo(DOT)s(AT)gmx.net

[David] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4360 days 19 hours and 33 minutes ago]

Mon, 5 May 2014 20:35:01 GMT

> Can you please tell me what you have selected in "Input Sources" on the
> system Keyboard sytem preferences panel?

Answer: U.S.

Which stands for United States. Macbook Pro, Mavericks.


> I don't see why you get '"' and then 'â€°' if you use the same key.
> And it only happens after saving the file?

I open a New file from the File menu in the POVRary3_7_Unofficial software. I
then enter:

#include “colors.inc”

using the double quote key just  nest to the Resturn key on my Macbook Pro
keyboard.

Then I save the file as demo.pov.

Then I render, and I get this error:

"/Users/davidarnold/Documents/temp/demo.pov"
 line 1
Parse Error: Illegal character in input file, value is d2.

If I open a new file and save it as demo.pov, then enter the code

#include “colors.inc”

I get the same error.

D.


yvo### [at] cancel_This_gmxnet (Yvo Smellenbergh) wrote:
> "David" <nomail@nomail> wrote:
>
> Can you please tell me what you have selected in "Input Sources" on the
> system Keyboard sytem preferences panel?
>
> I don't see why you get '"' and then 'â€°' if you use the same key.
> And it only happens after saving the file?
> Nobody ever reported this...
>
> Yvo
>
> > I've installed povray3_7_unofficial on my Mavericks mac laptop. When I
> > open a new file and try to use the double quotes key on my keyboard, I
> > get:
> >
> > include "color.incâ€° include "stones.incâ€° After
saving the file as
> > demo.pos, when I try to render the file, I get this error message.
> >
> > "/Users/davidarnold/Documents/temp/demo.pov" line 1 Parse Error: Illegal
> > character in input file, value is d2.
> >
> > Now if I create this code in BBEdit, save the file as demo.pov, then open
> > it in POVRay3_7_Unofficial, it looks like this:
> >
> > include "colors.inc" include "stones.inc" And it renders just fine.
> >
> > Why isn't the quotation key on my Mavericks Mac keyboard giving me the
> > correct quotation symbol in POVRay3_7_Unofficial? I also tried using
> > Courier and Helvetica, to no avail or difference.
> >
> > David.
>
>
> -- ----------------------------------- MegaPOV at:
> http://megapov.inetart.net MacMegaPOV at:
> http://users.skynet.be/smellenbergh E-mail: yvo(DOT)s(AT)gmx.net

[Le Forgeron] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4360 days 21 hours and 46 minutes ago]

Mon, 5 May 2014 18:22:16 GMT

Le 05/05/2014 18:57, Yvo Smellenbergh nous fit lire :
> "David" <nomail@nomail> wrote:
> 
> Can you please tell me what you have selected in "Input Sources" on the
> system Keyboard sytem preferences panel?
> 
> I don't see why you get '"' and then 'â€°' if you use the same key.
> And it only happens after saving the file?
> Nobody ever reported this... 
> 

In original message, I saw opening-quote and closing-quote (whereas
povray only wants straight-quote). Can it be related to editor mode or
something like that on Mac ?

If I was to see the same thing on my language, hitting:
#include "foo.inc"
would turns into
#include Â«foo.incÂ»
(which is also a no-no for povray)

(yep, I'm French, quotes are different) (and I have no Mac).

The issue is not the fonts, but the encoding (utf8 ?) generated by the "
key. Some smart layer is trying to make that an English text.

> Yvo
> 
>> I've installed povray3_7_unofficial on my Mavericks mac laptop. When I
>> open a new file and try to use the double quotes key on my keyboard, I
>> get:
>>
>> include "color.incâ€° include "stones.incâ€° After
saving the file as
>> demo.pos, when I try to render the file, I get this error message.
>>
>> "/Users/davidarnold/Documents/temp/demo.pov" line 1 Parse Error: Illegal
>> character in input file, value is d2.
>>
>> Now if I create this code in BBEdit, save the file as demo.pov, then open
>> it in POVRay3_7_Unofficial, it looks like this:
>>
>> include "colors.inc" include "stones.inc" And it renders just fine.
>>
>> Why isn't the quotation key on my Mavericks Mac keyboard giving me the
>> correct quotation symbol in POVRay3_7_Unofficial? I also tried using
>> Courier and Helvetica, to no avail or difference.
>>
>> David.
> 
> 
> -- ----------------------------------- MegaPOV at:
> http://megapov.inetart.net MacMegaPOV at:
> http://users.skynet.be/smellenbergh E-mail: yvo(DOT)s(AT)gmx.net
>

[Yvo Smellenbergh] Re: Quotation Marks Problem with POVRay3_7_Unoff... [4360 days 23 hours and 11 minutes ago]

Mon, 5 May 2014 16:57:05 GMT

"David" <nomail@nomail> wrote:

Can you please tell me what you have selected in "Input Sources" on the
system Keyboard sytem preferences panel?

I don't see why you get '"' and then 'â€°' if you use the same key.
And it only happens after saving the file?
Nobody ever reported this... 

Yvo

> I've installed povray3_7_unofficial on my Mavericks mac laptop. When I
> open a new file and try to use the double quotes key on my keyboard, I
> get:
> 
> include "color.incâ€° include "stones.incâ€° After
saving the file as
> demo.pos, when I try to render the file, I get this error message.
> 
> "/Users/davidarnold/Documents/temp/demo.pov" line 1 Parse Error: Illegal
> character in input file, value is d2.
> 
> Now if I create this code in BBEdit, save the file as demo.pov, then open
> it in POVRay3_7_Unofficial, it looks like this:
> 
> include "colors.inc" include "stones.inc" And it renders just fine.
> 
> Why isn't the quotation key on my Mavericks Mac keyboard giving me the
> correct quotation symbol in POVRay3_7_Unofficial? I also tried using
> Courier and Helvetica, to no avail or difference.
> 
> David.


-- ----------------------------------- MegaPOV at:
http://megapov.inetart.net MacMegaPOV at:
http://users.skynet.be/smellenbergh E-mail: yvo(DOT)s(AT)gmx.net

[David] Quotation Marks Problem with POVRay3_7_Unofficia... [4361 days 21 hours and 33 minutes ago]

Sun, 4 May 2014 18:35:01 GMT

I've installed povray3_7_unofficial on my Mavericks mac laptop. When I open a
new file and try to use the double quotes key on my keyboard, I get:

include “color.inc”
include “stones.inc”
After saving the file as demo.pos, when I try to render the file, I get this
error message.

"/Users/davidarnold/Documents/temp/demo.pov" line 1 Parse Error: Illegal
character in input file, value is d2.

Now if I create this code in BBEdit, save the file as demo.pov, then open it in
POVRay3_7_Unofficial, it looks like this:

include "colors.inc"
include "stones.inc"
And it renders just fine.

Why isn't the quotation key on my Mavericks Mac keyboard giving me the correct
quotation symbol in POVRay3_7_Unofficial? I also tried using Courier and
Helvetica, to no avail or difference.

David.

[Excentp] Re: Patch or Unofficial Version with Persistent ... [4386 days 19 hours and 38 minutes ago]

Wed, 9 Apr 2014 20:30:00 GMT

Christian Froeschlin <chr### [at] chrfrde> wrote:
> > If not, I would like to know how which POV-Ray source code files to alter so as
> > to be able to load unchanging object data only once and retain it for all
> > frames.
>
> Sorry for the long silence, you find me in continuous state of guilt.
>
> I did hack something together for this based on 3.7b34 (back in
> 2009 I think) with the intent of creating a real patch after 3.7
> proper was released. Of course that turned out to be a lot of
> years in between and now mostly busy with other things.
>
> After your post I thought I might give it a shot but I actually got
> stuck already getting 3.7 release to compile (new computer, new OS,
> new Visual Studio version, changed build) and think I won't be
> focussing on this anytime soon.
>
> I just dug up an old CVS repository from a backup of my last
> computers hard drive to find out what changes I did. Its a bit
> of a mess, really, I didn't plan to store this for eternity.
>
> Still I think the info could help you implement a patch for 3.7
> even if the codebase probably looks totally different than in 2009.
> The 5 files I changed were parse.h, parse.cpp, reswords.h, reswords.cpp
> and tokenize.cpp. I attach 2 zipfiles, one contains the state these
> files were in in 3.7b34 and one the files after my changes (because
> it's all a bit of a mess there can be changes regarding tokens
> for an aoi pattern in there too, ignore those).
>
> The basic idea of the change is to introduce a new symbol table.
> POVRay already had 2, one for reserved words and one for variables.
> The new symbol table is for static variables introduced using a
> new keyword #static instead of #declare. When a variable name
> is use, it is first looked up in the static table and then
> falls through to the dynamic table.
>
> Really the only difference between the tables is that I
> completely left out the code for freeing the static table
> after rendering. This has the following effects:
>
> In a command line environment, static variables values persist
> between frames of an animation.
>
> In an interactive GUI environment, static variables persist as
> long as the process is running. So you can run a single render
> that loads static variables, and when you run any other render
> it can still see that variable. In order to be complete such a
> patch should contain GUI functionality to show and clear the
> currently stored static variables.
>
> But even without it is very useful. It would be cool to see it
> implemented in an official version.
>
> Hope this helps,
>
>    Christian
>
> PS: Strictly speaking code changes based on beta version should not
> be published but the idea there is to prevent variants of unsupported
> and outdated versions making the rounds. I hope showing you one change
> I made in 2009 will not cause b34 to go rampant again :)

Christian

Of interest to me is the reswords.h. The current 3.7 has this line

#define SYM_ENTRY_REF_MAX           USHRT_MAX

in place of your changes

// Special symbol tables
#define ST_RESERVED_WORDS           0   // Reserved words only
#define ST_STATIC_SYMBOLS           1   // #static
#define ST_GLOBAL_SYMBOLS           2   // #declare / top-level #local

[Stephen] Re: crackle: suggested extensions [4405 days 4 hours and 53 minutes ago]

Sat, 22 Mar 2014 11:15:00 GMT

Anton Sherwood <bro### [at] poboxcom> wrote:
> On 2001-5-15 22:40, Anton Sherwood wrote:
> > ... Meanwhile, another idea: if (dx,dy,dz) were replaced with
> > (dx+dy,dx+dz,dy+dz), the `crystal' would be a rhombic dodecahedron.
>
> Or not.  Less than 13 years later, as I was thinking about something
> unrelated to ray-tracing, it hit me that it would have to be
>  (dx+dy, dx-dy, dx+dz, dx-dz, dy+dz, dy-dz).
>
> --
> *\\* Anton Sherwood *\\* www.bendwavy.org

You persevere I'll say that for you. :-)

[Anton Sherwood] Re: crackle: suggested extensions [4405 days 17 hours and 41 minutes ago]

Fri, 21 Mar 2014 22:27:06 GMT

> On 2001-5-15 22:40, Anton Sherwood wrote:
>> ... Meanwhile, another idea: if (dx,dy,dz) were replaced with
>> (dx+dy,dx+dz,dy+dz), the `crystal' would be a rhombic dodecahedron.

On 2014-2-07 20:45, Anton Sherwood wrote:
> Or not.  Less than 13 years later, as I was thinking about something
> unrelated to ray-tracing, it hit me that it would have to be
> 	(dx+dy, dx-dy, dx+dz, dx-dz, dy+dz, dy-dz).

Or ( abs(dx)+abs(dy), abs(dx)+abs(dz), abs(dy)+abs(dz) ),
which is probably what I meant in the first place.

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

[Christian Froeschlin] Re: Patch or Unofficial Version with Persistent ... [4410 days 21 hours and 52 minutes ago]

Sun, 16 Mar 2014 18:15:40 GMT

> If not, I would like to know how which POV-Ray source code files to alter so as
> to be able to load unchanging object data only once and retain it for all
> frames.

Sorry for the long silence, you find me in continuous state of guilt.

I did hack something together for this based on 3.7b34 (back in
2009 I think) with the intent of creating a real patch after 3.7
proper was released. Of course that turned out to be a lot of
years in between and now mostly busy with other things.

After your post I thought I might give it a shot but I actually got
stuck already getting 3.7 release to compile (new computer, new OS,
new Visual Studio version, changed build) and think I won't be
focussing on this anytime soon.

I just dug up an old CVS repository from a backup of my last
computers hard drive to find out what changes I did. Its a bit
of a mess, really, I didn't plan to store this for eternity.

Still I think the info could help you implement a patch for 3.7
even if the codebase probably looks totally different than in 2009.
The 5 files I changed were parse.h, parse.cpp, reswords.h, reswords.cpp
and tokenize.cpp. I attach 2 zipfiles, one contains the state these
files were in in 3.7b34 and one the files after my changes (because
it's all a bit of a mess there can be changes regarding tokens
for an aoi pattern in there too, ignore those).

The basic idea of the change is to introduce a new symbol table.
POVRay already had 2, one for reserved words and one for variables.
The new symbol table is for static variables introduced using a
new keyword #static instead of #declare. When a variable name
is use, it is first looked up in the static table and then
falls through to the dynamic table.

Really the only difference between the tables is that I
completely left out the code for freeing the static table
after rendering. This has the following effects:

In a command line environment, static variables values persist
between frames of an animation.

In an interactive GUI environment, static variables persist as
long as the process is running. So you can run a single render
that loads static variables, and when you run any other render
it can still see that variable. In order to be complete such a
patch should contain GUI functionality to show and clear the
currently stored static variables.

But even without it is very useful. It would be cool to see it
implemented in an official version.

Hope this helps,

   Christian

PS: Strictly speaking code changes based on beta version should not
be published but the idea there is to prevent variants of unsupported
and outdated versions making the rounds. I hope showing you one change
I made in 2009 will not cause b34 to go rampant again :)

[Yvo Smellenbergh] Update UberPOV for Mac GUI [4432 days 22 hours ago]

Sat, 22 Feb 2014 18:07:40 GMT

There is a little update available for UberPOV GUI version for Mac:
http://megapov.inetart.net/uberpov_mac/index.html#Mac
This is a fix for the preview window, it wasn't always updates
completely.

There are no changes for the command line version.

Yvo


-- 
-----------------------------------
MegaPOV at:  http://megapov.inetart.net
MacMegaPOV at:  http://users.skynet.be/smellenbergh
E-mail: yvo(DOT)s(AT)gmx.net

[Excentp] Patch or Unofficial Version with Persistent Vari... [4439 days 10 hours and 43 minutes ago]

Sun, 16 Feb 2014 05:25:01 GMT

I am currently working on a project that involves creating animation frames for
a mesh2 object with at 400,000 triangles and one light source.

I've already voiced my concern at the animation forum, but replies have been
slow.

So my issue is that my scene is being reparsed into around 3000 K tokens every
time prior to rendering the frame. The mesh contains the bulk of the information
for my scene, but it is unchanged throughout the animation. The only thing that
changed is the location of the light source.

So what I would like to know is if UberPOV has any plans to include persistent
variables and objects like what MegaPOV in its very early versions?

If not, I would like to know how which POV-Ray source code files to alter so as
to be able to load unchanging object data only once and retain it for all
frames.

[Yvo Smellenbergh] UberPOV v1.37.0.0-beta.4 released For Mac [4445 days and 15 minutes ago]

Mon, 10 Feb 2014 15:52:50 GMT

clipka <ano### [at] anonymousorg> wrote:

> Get the Windows binaries or the source code here:
> 
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4

And for the Mac versions (GUI and command line) go to:
http://megapov.inetart.net/uberpov_mac/index.html#Mac
Updated to beta 4 also.

Yvo

-- 
-----------------------------------
MegaPOV at:  http://megapov.inetart.net
MacMegaPOV at:  http://users.skynet.be/smellenbergh
E-mail: yvo(DOT)s(AT)gmx.net

[Anton Sherwood] Re: crackle: suggested extensions [4447 days 11 hours and 22 minutes ago]

Sat, 8 Feb 2014 04:45:59 GMT

On 2001-5-15 22:40, Anton Sherwood wrote:
> ... Meanwhile, another idea: if (dx,dy,dz) were replaced with
> (dx+dy,dx+dz,dy+dz), the `crystal' would be a rhombic dodecahedron.

Or not.  Less than 13 years later, as I was thinking about something 
unrelated to ray-tracing, it hit me that it would have to be
	(dx+dy, dx-dy, dx+dz, dx-dz, dy+dz, dy-dz).

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

[clipka] Re: Bug in UberPOV beta 4 x64. [4463 days 2 hours and 37 minutes ago]

Thu, 23 Jan 2014 13:30:43 GMT

Am 23.01.2014 13:04, schrieb fomhorian:

> Might it be possible for UberPOV to
> have an adaptive range for the +r? Something like +ra9,512...

That wouldn't make any sense; the oversampling algorithm is adaptive 
already, with the +r parameter just specifying the absolute maximum 
number of rays per pixel.

The minimum number of rays per pixel is automatically computed from the 
+a and +ac settings.

[fomhorian] Re: Bug in UberPOV beta 4 x64. [4463 days 4 hours and 3 minutes ago]

Thu, 23 Jan 2014 12:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 22.01.2014 11:05, schrieb fomhorian:
> > I'm getting black lines & patches no matter what. :/
> >
> > Code:
> >
> > // +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800
>                                 ^^^^^ ^^^^^ ^^^^^^^^^^^
>
> The settings interact as follows:
>
> The "+a0.1" setting specifies that you accept an error(*) of up to 10%
> per pixel. This is quite a lax setting, for high-quality renders I'd
> recommend "+a.01".
>
> (*The error margin is relative to 100% white for pixels somewhere
> between black and white; for brighter pixels, the error margin is
> relative to the resulting pixel colour itself.)
>
> The "+ac0.999995" setting specifies that you want a 99.9995% confidence
> that any given pixel is indeed within the accepted marging of error; an
> equivalent statement (at least in layman's terms) is that you accept
> 0.0005% of all pixels to be outside the accepted margin of error. This
> is an extremely strict setting, for high-quality renders I'd recommend
> something about "+ac0.99".
>
> The "+r512" option specifies how many samples you accept for any given
> pixel to be taken in the worst case; the value is not taken literally,
> but rather according to the formula:
>
>      max_samples = 4^r
>
> (The rationale behind this parameterization is that it is similar in
> order of magnitude as the effective maximum number of samples in
> anti-aliasing mode 2, while at the same time being easy to express as a
> formula.)
>
> I guess I don't need to tell you that 4^512 (= ca. 10^308) is much more
> than you'll ever need, and in a worst-case scenario could stall your
> render for just a bit short of eternity. For practical purposes, "+r9"
> should be enough for any render.
>
>
> To sum it up, for practical purposes the following settings should be ok
> for high-quality renders:
>
>      +am3 +a0.01 +ac0.99 +r9
>
>
> If you experience excessive noise, try lowering the "+a0.01" setting.
>
> If you experience stray dot artifacts, try increasing the "+ac0.99" setting.
>
> Further increasing the "+r9" setting should typically not be necessary.
>
>
> That said, it seems that you indeed have spotted a problem in UberPOV,
> but it's not related to blurred reflections. Somehow, the perturbed
> normals of the plane appear to lead to nonsense results very close to
> the horizon, leading to invalid colour values for individual rays, which
> sort of "dominate" the results for any other rays shot for the same
> pixel and (in the Windows version) manifest as pitch black pixels. (In
> the Linux version, they may lead to bright white pixels instead.)
>
> I'll have to investigate whether these nonsense results are indicative
> of an actual bug that needs to be fixed, or rather rare but inevitable
> consequences of rounding errors that can safely be worked around.

Well; I usually render with +a0.005, & I did start with +ac0.95...
I was surprised that POVRay could take +r512 actually & it still rendered way
quicker than my standard aa-settings & +AM2. Might it be possible for UberPOV to
have an adaptive range for the +r? Something like +ra9,512...

                                             Cheers from Sweden!

[clipka] Re: Bug in UberPOV beta 4 x64. [4463 days 22 hours and 2 minutes ago]

Wed, 22 Jan 2014 18:06:04 GMT

Am 22.01.2014 11:05, schrieb fomhorian:
> I'm getting black lines & patches no matter what. :/
>
> Code:
>
> // +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800
                                ^^^^^ ^^^^^ ^^^^^^^^^^^

The settings interact as follows:

The "+a0.1" setting specifies that you accept an error(*) of up to 10% 
per pixel. This is quite a lax setting, for high-quality renders I'd 
recommend "+a.01".

(*The error margin is relative to 100% white for pixels somewhere 
between black and white; for brighter pixels, the error margin is 
relative to the resulting pixel colour itself.)

The "+ac0.999995" setting specifies that you want a 99.9995% confidence 
that any given pixel is indeed within the accepted marging of error; an 
equivalent statement (at least in layman's terms) is that you accept 
0.0005% of all pixels to be outside the accepted margin of error. This 
is an extremely strict setting, for high-quality renders I'd recommend 
something about "+ac0.99".

The "+r512" option specifies how many samples you accept for any given 
pixel to be taken in the worst case; the value is not taken literally, 
but rather according to the formula:

     max_samples = 4^r

(The rationale behind this parameterization is that it is similar in 
order of magnitude as the effective maximum number of samples in 
anti-aliasing mode 2, while at the same time being easy to express as a 
formula.)

I guess I don't need to tell you that 4^512 (= ca. 10^308) is much more 
than you'll ever need, and in a worst-case scenario could stall your 
render for just a bit short of eternity. For practical purposes, "+r9" 
should be enough for any render.


To sum it up, for practical purposes the following settings should be ok 
for high-quality renders:

     +am3 +a0.01 +ac0.99 +r9


If you experience excessive noise, try lowering the "+a0.01" setting.

If you experience stray dot artifacts, try increasing the "+ac0.99" setting.

Further increasing the "+r9" setting should typically not be necessary.


That said, it seems that you indeed have spotted a problem in UberPOV, 
but it's not related to blurred reflections. Somehow, the perturbed 
normals of the plane appear to lead to nonsense results very close to 
the horizon, leading to invalid colour values for individual rays, which 
sort of "dominate" the results for any other rays shot for the same 
pixel and (in the Windows version) manifest as pitch black pixels. (In 
the Linux version, they may lead to bright white pixels instead.)

I'll have to investigate whether these nonsense results are indicative 
of an actual bug that needs to be fixed, or rather rare but inevitable 
consequences of rounding errors that can safely be worked around.

[James Holsenback] Re: Bug in UberPOV beta 4 x64. [4464 days 5 hours and 23 minutes ago]

Wed, 22 Jan 2014 10:44:50 GMT

On 01/22/2014 05:05 AM, fomhorian wrote:
> I'm getting black lines & patches no matter what. :/
>
> Code:
>
> // +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800

                                        ^---- Yikes!!!!

> // Rendertime 12min 55sek
> // Win 8.1Pro x64 on AMD PhenomII with 8 GB ram
> #version unofficial patch 3.7;
> #patch "upov-reflection-roughness" 0.9;
>
> global_settings{ assumed_gamma 2.2 max_trace_level 36 }
>
> #default{ finish{ ambient 0.1 diffuse 0.7 }}
>
> camera {
>   perspective angle 75 location  <0.0 , 1.0 ,-3.0>  right
> x*image_width/image_height look_at <0.0 , 1.0 , 0.0>
>   aperture 0.025 blur_samples 512,2048 focal_point <0,1.0,0> confidence 0.999
> variance 0.001
> }
>
> light_source{ < 3000,3000,-3000> color rgb 1 }
>
> sky_sphere { pigment { gradient y
>   color_map { [0.00 rgb <0.6,0.7,1.0>][0.35 rgb <0.1,0.3,0.8>][0.65 rgb
> <0.1,0.3,0.8>][1.00 rgb <0.6,0.7,1.0>]}
>   scale 2 }
> }
>
> plane{ <0,1,0>, 0
>         texture{ pigment{ checker color rgb<1,1,1>*1.2 color
> rgb<0.25,0.15,0.1>*0.05 }
>                  normal { bumps 0.75 scale 0.1 turbulence 0.5 omega 0.4 lambda
> 2.5 octaves 6 }
>                  finish { specular 0.1 roughness 0.1 }
>                }
>       }
>
> sphere { <0,0,0>, 1.00
>           texture {
>                     pigment{ color rgb <1,0,0> }
>                     finish { specular 1.0 roughness 0.0125 brilliance 2
> reflection { 0.5 metallic 0.5 roughness 0.0125 } }
>                   }
>
>            scale<1,1,1>  rotate<0,0,0>  translate<0,1.35,0>
>         }  // end of sphere -----------------------------------
>
> I would have liked to paste or attach an image here but...
> I've tried to vary the +r, the +ac & the number of samples that the
> focal blur uses, also the conf & vari, but no success.
> The black patches only exist at the horizon while the lines/dots are
> on the sphere.

I think the expectation that you can overcome the moire' effect of the 
checked plane at the horizon is unrealistic ... I mean +r512 holy moley!

[fomhorian] Bug in UberPOV beta 4 x64. [4464 days 5 hours and 58 minutes ago]

Wed, 22 Jan 2014 10:10:00 GMT

I'm getting black lines & patches no matter what. :/

Code:

// +FN16 +BS5 +RP4 +RVP +am3 +a0.1 +r512 +ac0.999995 +w800 +h800
// Rendertime 12min 55sek
// Win 8.1Pro x64 on AMD PhenomII with 8 GB ram
#version unofficial patch 3.7;
#patch "upov-reflection-roughness" 0.9;

global_settings{ assumed_gamma 2.2 max_trace_level 36 }

#default{ finish{ ambient 0.1 diffuse 0.7 }}

camera {
 perspective angle 75 location  <0.0 , 1.0 ,-3.0>  right
x*image_width/image_height look_at <0.0 , 1.0 , 0.0>
 aperture 0.025 blur_samples 512,2048 focal_point <0,1.0,0> confidence 0.999
variance 0.001
}

light_source{ < 3000,3000,-3000> color rgb 1 }

sky_sphere { pigment { gradient y
 color_map { [0.00 rgb <0.6,0.7,1.0>][0.35 rgb <0.1,0.3,0.8>][0.65 rgb
<0.1,0.3,0.8>][1.00 rgb <0.6,0.7,1.0>]}
 scale 2 }
}

plane{ <0,1,0>, 0
       texture{ pigment{ checker color rgb<1,1,1>*1.2 color
rgb<0.25,0.15,0.1>*0.05 }
                normal { bumps 0.75 scale 0.1 turbulence 0.5 omega 0.4 lambda
2.5 octaves 6 }
                finish { specular 0.1 roughness 0.1 }
              }
     }

sphere { <0,0,0>, 1.00
         texture {
                   pigment{ color rgb <1,0,0> }
                   finish { specular 1.0 roughness 0.0125 brilliance 2
reflection { 0.5 metallic 0.5 roughness 0.0125 } }
                 }

          scale<1,1,1>  rotate<0,0,0>  translate<0,1.35,0>
       }  // end of sphere -----------------------------------

I would have liked to paste or attach an image here but...
I've tried to vary the +r, the +ac & the number of samples that the
focal blur uses, also the conf & vari, but no success.
The black patches only exist at the horizon while the lines/dots are
on the sphere.

                                   Sincerely Rendering!

[clipka] Re: UberPOV v1.37.0.0-beta.4 released [4467 days 3 hours and 17 minutes ago]

Sun, 19 Jan 2014 12:50:18 GMT

Am 19.01.2014 08:23, schrieb MichaelJF:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 18.01.2014 20:35, schrieb MichaelJF:
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> Get the Windows binaries or the source code here:
>>>>
>>>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4
>>>
>>> I had some difficulties to persuade Win 8.1 to run the program but prevailed
>>> finally.
>>
>> What kind of difficulties?
>>
> My fault. I tried to run the setup from winzip directly, but one has to extract
> it to disk to get administrator rights, I learned yesterday.

Setup? What setup? :-P

[MichaelJF] Re: UberPOV v1.37.0.0-beta.4 released [4467 days 8 hours and 43 minutes ago]

Sun, 19 Jan 2014 07:25:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 18.01.2014 20:35, schrieb MichaelJF:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Get the Windows binaries or the source code here:
> >>
> >> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4
> >
> > I had some difficulties to persuade Win 8.1 to run the program but prevailed
> > finally.
>
> What kind of difficulties?
>
My fault. I tried to run the setup from winzip directly, but one has to extract
it to disk to get administrator rights, I learned yesterday.

Best regards,
Michael

[clipka] Re: UberPOV v1.37.0.0-beta.4 released [4467 days 11 hours and 16 minutes ago]

Sun, 19 Jan 2014 04:51:46 GMT

Am 19.01.2014 02:41, schrieb Cousin Ricky:
> clipka <ano### [at] anonymousorg> wrote:
>> Primary reason for release was a fix for the blurred reflections bug
>> just pointed out by Cousin Ricky.
>
> Wow.  I feel important!

:-)

> That was a rapid fix!  Or so I'm assuming, as I'm in the middle of a run right
> now and can't test it.

Well, starting from the analysis you had already provided - that it 
occurred only with some primitives - it was a piece of cake to locate 
the bug, and it happened to be easy to get rid of.

[Cousin Ricky] Re: UberPOV v1.37.0.0-beta.4 released [4467 days 14 hours and 23 minutes ago]

Sun, 19 Jan 2014 01:45:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Primary reason for release was a fix for the blurred reflections bug
> just pointed out by Cousin Ricky.

Wow.  I feel important!

That was a rapid fix!  Or so I'm assuming, as I'm in the middle of a run right
now and can't test it.

[clipka] Re: UberPOV v1.37.0.0-beta.4 released [4467 days 18 hours and 19 minutes ago]

Sat, 18 Jan 2014 21:48:40 GMT

Am 18.01.2014 20:35, schrieb MichaelJF:
> clipka <ano### [at] anonymousorg> wrote:
>> Get the Windows binaries or the source code here:
>>
>> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4
>
> I had some difficulties to persuade Win 8.1 to run the program but prevailed
> finally.

What kind of difficulties?

> Can you point out the changes to the last version?

Primary reason for release was a fix for the blurred reflections bug 
just pointed out by Cousin Ricky.

On that occasion, I also pulled in the most recent changes to the 
official POV-Ray "master" branch.

beta.4 also includes a fix for a bug in the AA mode 3 that was 
discovered shortly after release of beta.3.

[MichaelJF] Re: UberPOV v1.37.0.0-beta.4 released [4467 days 20 hours and 28 minutes ago]

Sat, 18 Jan 2014 19:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Get the Windows binaries or the source code here:
>
> https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4

I had some difficulties to persuade Win 8.1 to run the program but prevailed
finally. Can you point out the changes to the last version?

Best regards,
Michael

[clipka] UberPOV v1.37.0.0-beta.4 released [4467 days 21 hours and 45 minutes ago]

Sat, 18 Jan 2014 18:22:28 GMT

Get the Windows binaries or the source code here:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.4

[clipka] Re: Bug in UberPOV blurred reflection [4468 days 9 hours and 17 minutes ago]

Sat, 18 Jan 2014 06:50:33 GMT

Am 17.01.2014 22:16, schrieb Cousin Ricky:
> Blurred reflection doesn't work on some surfaces parallel to the in the x-y
> plane.  (It's a problem for planes and boxes, but not for cylinders.)  The
> following scene file illustrates the problem.  The cube on the right has been
> rotated ever so slightly, and the problem does not show up.

That's seriously odd; for the blurred reflections algorithm it shouldn't 
make any difference which type of primitive is used - all it knows and 
cares about is the surface normal.

The only conclusion I can draw from this (after having confirmed your 
observations) is that there are two issues involved here:

(1) A flaw in the box code that makes it return a flipped normal for the 
x-y faces. (This isn't strictly a bug, as the code downstream is 
supposed to cope with flipped normals.)

(2) A bug in the blurred reflection code that makes it break down if the 
normal is either +z or -z and points the wrong way round. (Most likely 
the bug is not in the blurred reflections code itself, but auxiliary 
code that is supposed to flip the normal as needed.)


(BTW, experiments show that cylinders /are/ affected as well, but only 
at one end.)

[Cousin Ricky] Bug in UberPOV blurred reflection [4468 days 18 hours and 48 minutes ago]

Fri, 17 Jan 2014 21:20:01 GMT

Blurred reflection doesn't work on some surfaces parallel to the in the x-y
plane.  (It's a problem for planes and boxes, but not for cylinders.)  The
following scene file illustrates the problem.  The cube on the right has been
rotated ever so slightly, and the problem does not show up.
_______________________________________________________

// +am3 +a0.01 +ac0.999 +r5 +w400 +h225
#version unofficial patch 3.7;
#patch "upov-reflection-roughness" 0.9;

#ifndef (Dolly) #declare Dolly = 0; #end
#ifndef (Boom) #declare Boom = 0; #end

global_settings { assumed_gamma 1  }
#default { finish { diffuse 0.6 ambient rgb 0.16041 } }
camera
{ location <0, 1, -5.6713>
  look_at <0, 1, 0>
  right 1.7778 * x
  up 1.0 * y
  angle 50.3663
  rotate <Boom, Dolly, 0>
}
light_source
{ <-3.3125, 7.6250, -5.7374>, rgb 4045.5
  fade_power 2 fade_distance 0.10417
  spotlight point_at <0, 1, 0> radius 45 falloff 90
}
box
{ -<7, 9, 7>, <7, 9, 7> hollow
  pigment { rgb 1 }
}
plane
{ y, 0
  pigment { checker rgb 0.05 rgb 1 }
}

//============================================

#declare Test = box
{ -1, 1
  pigment { rgb <0.9713, 0.7420, 0.3277> }
  finish
  { ambient 0 diffuse 0
    reflection { 1 metallic roughness 0.0002 }
    specular 1 metallic 1 roughness 0.0002
  }
}

object
{ Test
  translate <-1.1, 1, 0>
}
object
{ Test
  rotate 0.000001 * y
  translate <1.1, 1, 0>
}
_______________________________________________________

POV-Ray version: UberPOV 1.37.0.0-beta.3
Operating system: openSUSE 13.1 GNU/Linux
Hardware: Dell Inspiron 17R, Intel Core i7

[clipka] Re: UberPOV stochastic anti-aliasing question [4469 days 19 hours and 44 minutes ago]

Thu, 16 Jan 2014 20:23:25 GMT

Am 16.01.2014 19:28, schrieb Cousin Ricky:
> Does the jitter switch (+J, -J) have any meaning in the context of stochastic
> anti-aliasing?

No.

[Cousin Ricky] UberPOV stochastic anti-aliasing question [4469 days 21 hours and 38 minutes ago]

Thu, 16 Jan 2014 18:30:01 GMT

Does the jitter switch (+J, -J) have any meaning in the context of stochastic
anti-aliasing?

[clipka] Re: Progress Reporting Change? [4483 days 17 hours and 54 minutes ago]

Thu, 2 Jan 2014 22:13:44 GMT

Am 02.01.2014 19:17, schrieb Alain:
> Le 13-12-31 06:50, James Holsenback a écrit :
>> Just noticed that progress reporting seems to be different with uber-dev
>> branch ... talking about the rendered xxx of xxxx (xx%) message.
>>
>> The % indication /used/ to reset to 0 at the end of each pretrace step,
>> before starting the next step. Now it appears that it doesn't reset to 0
>> until it starts the final trace.

> I noted the same thing with the official version 3.7, back to RC1 and
> maybe earlier. The percent of the pretrace seems to be calculated on the
> TOTAL pretrace process, not on any individual pretrace step.

Yes, that observation is correct, and this behaviour is intentional.