povray.binaries.programming message digest

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 6012c3f5 [86 days 12 hours and 39 minutes ago]

Sat, 24 Jan 2026 13:58:20 GMT

On 1/24/26 08:56, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_6012c3f5.tar.gz and 
> yuqk_Examples_6012c3f5.tar.gz files will be attached to a response to 
> this posting.

Bill P.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. 6012c3f5 [86 days 12 hours and 41 minutes ago]

Sat, 24 Jan 2026 13:56:36 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_6012c3f5.tar.gz and 
yuqk_Examples_6012c3f5.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. Those using g++ compiler version 13 or later must add the compiler 
flag -fno-finite-math-only, if using the flag -ffast-math.

Note. Those compiling to the c++20 (or later) standard must currently 
use the -fno-char8_t compiler flag.

Bill P.


---------------- povray-3.8.0-x.yuqk_6012c3f5.tar.gz  January 24, 2026
yuqk R20 v0.6.14.0

Implemented additional updates to the initial bounding checks for ray 
surface intersections of the sor{} shape as suggested / inspired by Bill 
Walker's investigations.

Removed the warning: "CSG union unnecessarily bounded." due it too often 
being misleading. Testing whether an object using bounded_by{} is 
'finite' far from enough to determine that any manual bounding is 
unnecessary.

Adopted fix for 'Fixed' type set up in truetype.cpp, as worked out by: 
cho-m (Michael Cho), ryandesign (Ryan Carsten Schmidt) and trevorsandy 
(Trevor SANDY). See: https://github.com/POV-Ray/povray/issues/479

The disc and polygon shape types changed from BASIC_OBJECT to 
PATCH_OBJECT to enable some additional parser checking. No functional 
change expected.

Adding a new 'mode <integer>' keyword to the bounded_by{} and 
clipped_by{} features extending functionality, especially, where 
multiple bounded_by{} and clipped_by{} shapes are used.

Fixed / (made reliable) disc{} CSG operations by removing the planar 
inside test associated with it. The shape now has an inside test which 
always returns false aligning it with the current behavior of other 
patch like objects like the polygon{} shape. There have long been GSC 
bugs with disc{}s with respect to documented and coded behavior for the 
inside test. Ref: 
https://news.povray.org/povray.beta-test/thread/%3C68d3b3a7%40news.povray.org%3E/

Added a parser check for the cone{} shape to prevent either base or apex 
radius being negative. The code doesn't fully function for such dual 
cone specifications due some bounding issue. Plan is to fix the issue at 
some later time and remove the parse time check.

Moved a missed EPSILON in lathe.cpp's Lathe::UVCoord() to 
gkMinIsectDepthReturned. Also other code clean up. No functional change 
expected.

Changes in sor{}: Fix for segment blink out issue. Tuning zeroing 
thresholds related to A,B,C,D calculated values to avoid noisy results. 
Adding 'caps' and 'intervals' options and relaxing the existing 'open' 
syntax. Allowing control points to be negative. Adding more information 
to some previously generic point list error messages.

Parser update to make the global_settings{ subsurface{} } feature 
illegal until such time as I can debug why the yuqk parser hangs in an 
infinite loop.  Where the global_settings{} subsurface{} is specified, 
the parser hangs once any object is used in a scene . It doesn't matter 
whether the object is using the subsurface feature or not. The yuqk code 
was working in November of 2021, but not in any recent yuqk release.

Removed a particular use of constexpr using std::pow() in 
f_popnrm_rnoise() which was causing compile problems using Xcode 13.2.1 
on Mac OS Big Sur 11.7.10. Problem reported by Mr on POV-Ray news groups.

Minor updates to parametric{}. Trying cleaner set up code.

Updated starter povray.ini file to better reflect yuqk fork being linux 
/ Unix only.

Updated how some of the internal keyword information is maintained so it 
better aligns with how the vim .pov syntax and .ini syntax files are 
maintained. The updates also set things up better for future ini options 
and command line work.

ASCII control characters, excepting a few which are used and expected, 
have been made illegal in .ini files. This includes the horizontal tab 
character after such a tab again caused trouble.

Re-enabling some pov_mem debugging ability. Setting -DMEM_GUARD 
-DMEM_TAG during configuration for a build enables the debugging.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. b55a38d3 [340 days 20 hours and 45 minutes ago]

Thu, 15 May 2025 05:52:24 GMT

On 5/14/25 18:17, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please see the attached tarballs, previous announcements in this forum
>> and INSTALL.txt for suggestions on compiling and running via wrapper script.
> 
> thanks ! I followed the install.txt and...
> 
> * it did compile and check on my Ubuntu 24.04 !
> 
> *Less so on my Intel Mac OS Big Sur 11.7.10
> 
> there a) I had to compile with CXXFLAGS="-std=c++17 -O2" but even then, I got an
> error:
> 
>    CXX      vm/fnintern.o
> vm/fnintern.cpp:5483:29: error: constexpr variable 'tmpPow2_52' must be
> initialized by a constant expression
>      static constexpr double tmpPow2_52 = std::pow(2.0,52.0);
>                              ^            ~~~~~~~~~~~~~~~~~~
> 
> And before that a warning:
> parser/parser_expressions.cpp:2993:13: warning: enumeration value
> 'kBlendMapType_Slope' not handled in switch [-Wswitch]
>      switch (Blend_Type)
>              ^
> 
> these warning happen both with Xcode 13.2.1 and  brew installed gcc-14
> 

Thanks for the information!

I had some trouble between g++ and clang++ too with what is considered a 
valid constexpr; g++ tends to allow more. I'll put that usage on the 
list to change to something more basic.

I'm aware of the kBlendMapType_Slope warning. I'm buried in my attempt 
at alternate options parsing at the moment, but IIRC there is some funky 
stuff going due there traditionally being a couple of blendmap set ups.

One for normal perturbations (blendmap.h ?) and another for value 
patterns. They are now both 'sort of' merged in the current pattern.h 
pattern.cpp and parsing implementations.

I think the merge (at v3.7 I'd guess) is why there are some commented 
entries and an odd value set up in blendmap.h - some enumeration values 
are skipped. I looked at it once, but couldn't get my head around a 
clean way to sort it in the time I was willing to spend. With the 
warning there, things are not really broken as I see it - though 
admittedly not pretty.

Bill P.

[Mr] Re: Updated yuqk tarballs for Unix/Linux. b55a38d3 [341 days 4 hours and 17 minutes ago]

Wed, 14 May 2025 22:20:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarballs, previous announcements in this forum
> and INSTALL.txt for suggestions on compiling and running via wrapper script.

thanks ! I followed the install.txt and...

* it did compile and check on my Ubuntu 24.04 !

*Less so on my Intel Mac OS Big Sur 11.7.10

there a) I had to compile with CXXFLAGS="-std=c++17 -O2" but even then, I got an
error:

  CXX      vm/fnintern.o
vm/fnintern.cpp:5483:29: error: constexpr variable 'tmpPow2_52' must be
initialized by a constant expression
    static constexpr double tmpPow2_52 = std::pow(2.0,52.0);
                            ^            ~~~~~~~~~~~~~~~~~~

And before that a warning:
parser/parser_expressions.cpp:2993:13: warning: enumeration value
'kBlendMapType_Slope' not handled in switch [-Wswitch]
    switch (Blend_Type)
            ^

these warning happen both with Xcode 13.2.1 and  brew installed gcc-14

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. b55a38d3 [384 days 17 hours and 53 minutes ago]

Tue, 1 Apr 2025 08:44:10 GMT

On 4/1/25 04:38, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_b55a38d3.tar.gz and 
> yuqk_Examples_b55a38d3.tar.gz files will be attached to a response to 
> this posting.


Bill P.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. b55a38d3 [384 days 17 hours and 58 minutes ago]

Tue, 1 Apr 2025 08:39:02 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_b55a38d3.tar.gz and 
yuqk_Examples_b55a38d3.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. Those using g++ compiler version 13 or later must add the compiler 
flag -fno-finite-math-only, if using the flag -ffast-math.

Note. Those compiling to the c++20 (or later) standard must currently 
use the -fno-char8_t compiler flag.

Bill P.

---------------- povray-3.8.0-x.yuqk_b55a38d3.tar.gz  April 01, 2025
yuqk R19 v0.6.13.0

Minor syntax checking additions for the #switch directive and related 
keywords.

Added support for 2D surface outputs with text{} by using a zero 
thickness and the new 'caps' feature.

Added some trial checking of passed text{} and sphere{} identifiers in 
the debug build of yuqk. In addition to testing a way to check the type 
of passed objects, it prevents potential issues where users might wrap a 
general object - not a sphere identifier - with, for example, sphere { 
Light00 }. Users running the debugging compile are also prevented from 
using text { TextID }, as text{} assignments to IDs are creating an 
internal union{} (or optionally in yuqk, a merge{}). In other words, all 
text identifiers should be wrapped with object{} after the initial 
definition.

Added the keywords 'caps', 'merge' and 'open' to the text{} object. The 
'caps' and 'open' keywords implementing what might become general where 
objects already support 'open'. Namely, allowing the return of the caps 
/ ends or 'sides' of objects separately. The 'merge' keyword creates an 
internal merge{} of individual characters rather than a union{} - a 
necessary option where any transparency involved.

Fixed a longstanding issue with the offset vector in the text{} object 
where the z component was being ignored. The z component support is 
necessary where adjacent font characters overlap by design - otherwise 
there is no way to avoid coincident surfaces in the resulting text{} 
union of individual characters.

Fixed the support for negative thickness settings in the text{} object. 
Only the ends or caps were working correctly.

Removed the generation of parse time warnings for experimental and beta 
features. The yuqk fork is in total a test lab for potential v4.0 changes.

Added a DocAidScenes directory scene seeWebHexColor.pov.

The tiny internal rotation created and applied within the text{} object 
code to avoid axis aligned numerical noise is being removed in this 
release as a trial change. It likely makes more sense to make this 
numerical-patch be something the user does when needed.

Fixed a bug introduced in the text{} object code during v3.8 code 
development which was occasionally causing segment faults / invalid 
memory accesses.

Adding the inbuilt function f_kappa_2d() which can be used to mate up 
two 2D curves of any kind at (t), if one has access to the first and 
second derivatives of both curves.

Adding the inbuilt functions: f_bezier_2d_linear() 
f_bezier_2d_quadratic() f_bezier_2d_cubic() f_bezier_2d_quartic() and 
f_bezier_2d_quintic().

Better handling for bump_map{} image seams.

[kurtz le pirate] Re: yuqk errors [420 days 11 hours and 35 minutes ago]

Mon, 24 Feb 2025 15:02:24 GMT

On 24/02/2025 13:52, jr wrote:

> 
> you built without the (poorly named :-)) '--disable-no-lc-identifiers' ?

Yes, I built with the default options.
Another parameter I missed in the documentation.

Come on, it'll give me some work to do and get back to shell control.

-- 
kurtz le pirate
compagnie de la banquise

[Bald Eagle] Re: yuqk errors [420 days 12 hours and 27 minutes ago]

Mon, 24 Feb 2025 14:10:00 GMT

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

> A quick aside I hope useful. A place where I've several times now gotten
> myself tangled up is with our relatively new #for loop. When you
> write:
>
>    #for (I,0,SphCnt,4)
>    ...
>    #end
>
> that 'I' is a created (or modified) identifier which persists. In the
> default yuqk build, it must be upper case, but I still forget that 'I'
> is not locally scoped to the for loop. If there is use of that 'I'
> outside the loop you can end up with an 'I' you didn't expect or, by
> accident, define an 'I' which should be defined / initialized in some
> other way.

This is something that I've run into as well, and for some reason I thought that
there was something in the docs that stated that loop inices were locally
scoped.  I could be wrong about that though.
I get nailed by this a lot when using functions, and I'm trying to use something
like "I" as a function parameter.  Grrr.

> One protection would be to add an '#undef I' immediately following the
> for loop when you are sure you don't need it to persist though I mostly
> fail to do it.
>
> I've though some about changing the implementation in yuqk so it does an
> internal #undef of the loop identifier / variable at loop's end, IF, the
> 'I' wasn't already defined. But, users sometimes would be doing things
> like breaking out and checking the 'I' value following the loop. I don't
> know... Just something to remember perhaps.

I definitely have code that I've written that does that and uses the final value
of I after the loop exits.

Perhaps something to consider is having #for or #while get invoked with an
option #undef flag, like we have shape macros that use union {} unless the "use
merge" flag is set.

If the flag gets set, you undef, if not, let it persist.
Or optionally, you could have the argument be an identifier that gets set to the
last I value - so the user is fully aware and intentionally releasing a globally
set variable into the wild.

Seems like maybe some of this just holds onto a can of worms and may encourage
poor coding practices.

I'm not sure what best practice is, but I personally would lean toward just the
locally encapsulated form.
I suppose if the ultimate I value is needed outside the loop, then the user can
(wastefully and continually) #declare an identifier (inside the loop) before
exiting.

Perhaps some other "real" language has a construct or programming paradigm that
best handles this?

- BW

[William F Pokorny] Re: yuqk errors [420 days 13 hours and 3 minutes ago]

Mon, 24 Feb 2025 13:33:59 GMT

On 2/24/25 06:34, kurtz le pirate wrote:
> Porting scene from standard 3.8 version to last yuqk give me somme 
> errors like that :
> 
> The yuqk release 18 (3.8.0-x.yuqk_a5c25dda) version is: v0.6.12.0
> File 'vis_mesh03.pov' line 139:
> Parse Error:
> #local identifier 'i' using only a-z, 0-9 and _ characters.
> Fatal error in parser: Cannot parse input.
> Render failed

The yuqk fork, by default, builds with code that prevents the use of 
lower case user identifiers as these are too often the source of obscure 
bugs and meaning (*)(**). Also, with yuqk changing all the time, it is 
more likely I'll add some feature which collides some user's identifier 
if they are defining lower case ones. This happened when I created an 
'e' immediate value similar to the long existing 'pi'.

Users like jr, who only write and code in lower case, and folks with old 
scenes often have code with lower case characters, so there is an option 
to the configure script in:

   --disable-no-lc-identifiers

which you can add when you run ./configure to turn the checking off.

The installs of the yuqk core are small, One of the development builds I 
maintain is compiled with that option off as are all my prior version 
builds. I too often run into scenes with lower case identifiers.

---

A quick aside I hope useful. A place where I've several times now gotten 
myself tangled up is with our relatively new #for loop. When you
write:

   #for (I,0,SphCnt,4)
   ...
   #end

that 'I' is a created (or modified) identifier which persists. In the 
default yuqk build, it must be upper case, but I still forget that 'I' 
is not locally scoped to the for loop. If there is use of that 'I' 
outside the loop you can end up with an 'I' you didn't expect or, by 
accident, define an 'I' which should be defined / initialized in some 
other way.     		

One protection would be to add an '#undef I' immediately following the 
for loop when you are sure you don't need it to persist though I mostly 
fail to do it.

I've though some about changing the implementation in yuqk so it does an 
internal #undef of the loop identifier / variable at loop's end, IF, the 
'I' wasn't already defined. But, users sometimes would be doing things 
like breaking out and checking the 'I' value following the loop. I don't 
know... Just something to remember perhaps.

Bill P.

(*) Official POV-Ray releases ship with stuff defined in our include 
files which only look like inbuilt keywords and functions. These make 
code passed around less clear and less stable. Users are somewhat likely 
to create things by the same lower case name / identifier. Where these 
do not have the same functionality - but are defined by the totality of 
SDL included for the scene, the scene may run, but not render properly.

(**) - The 'ro_' read only prefix is another, new to yuqk, feature 
related to preventing obscure bugs where, say, a macro call using an 
identifier which exist outside the macros scope changes outside the 
macro itself due some #local or #declare use of the 'macro parameter 
name' within the called macro. This feature is also on by default in 
yuqk, but it too can be configured off by using:

   --disable-read-only-identifiers

when running ./configure.

[jr] Re: yuqk errors [420 days 13 hours and 42 minutes ago]

Mon, 24 Feb 2025 12:55:00 GMT

hi,


kurtz le pirate <kur### [at] freefr> wrote:
> ...
> The yuqk release 18 (3.8.0-x.yuqk_a5c25dda) version is: v0.6.12.0
> File 'vis_mesh03.pov' line 139:
> Parse Error:
> #local identifier 'i' using only a-z, 0-9 and _ characters.
> Fatal error in parser: Cannot parse input.
> Render failed
>
> I got this error for several variables.
> I just replaced "i" to "iVar", "_n" to "nVar", ... and it's OK.
>
> Strange, isn't it?
>

you built without the (poorly named :-)) '--disable-no-lc-identifiers' ?


regards, jr.

[kurtz le pirate] yuqk errors [420 days 15 hours and 3 minutes ago]

Mon, 24 Feb 2025 11:34:18 GMT

Hi,

Porting scene from standard 3.8 version to last yuqk give me somme 
errors like that :


The yuqk release 18 (3.8.0-x.yuqk_a5c25dda) version is: v0.6.12.0
File 'vis_mesh03.pov' line 139:
Parse Error:
#local identifier 'i' using only a-z, 0-9 and _ characters.
Fatal error in parser: Cannot parse input.
Render failed


I got this error for several variables.
I just replaced "i" to "iVar", "_n" to "nVar", ... and it's OK.



Strange, isn't it?



-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [428 days 18 hours and 30 minutes ago]

Sun, 16 Feb 2025 08:07:17 GMT

On 2/15/25 19:34, Bald Eagle wrote:
> It's the -inf that really has me puzzled!

Yes, it was that value which caused me to ask. :-)

What I remember is official POV-Ray had code, beyond the pattern-value 
modification code itself, which changed / mangled negative function 
return values ahead of the map handling. I don't remember the details.

It's possible there are differences in how the v3.8 executable you have 
was compiled. On the numerical fringes, compiler's and compiler settings 
can change quite a lot how odd values / NANs behave.

So as to better see what my working yuqk development compile does with 
the values, I changed the color_map to:

color_map {
     [-1.00 rgbt <1,1,0.3,1>]
     [0.00 rgb 0]
     [0.33 rgb x]
     [0.50-E rgb x]
     [0.50   rgbt 1]
     [0.50+E rgb y]
     [0.66 rgb y]
     [1.00 rgb z]
     [2.00 rgbt <1,1,0.6,1>]
}

I get:

Val(val("-inf")) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(-0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(+0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.013, 0.013, 0.000, 0.013
Val(0.5) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0.5+E) = 0.013, 1.000, 0.013, 0.000, 0.013
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(+0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("-nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("-0.33")) = 0.000, 0.971, 0.029, 0.000, 0.000

Adding yuqk's 'raw_wave' just below 'gradient x' I get:

Val(val("-inf")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(-0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(+0) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.013, 0.013, 0.000, 0.013
Val(0.5) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0.5+E) = 0.013, 1.000, 0.013, 0.000, 0.013
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(+0+1) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(val("+inf")) = 1.000, 1.000, 0.600, 0.000, 1.000
Val(val("-nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 0.300, 0.000, 1.000
Val(val("-0.33")) = 0.330, 0.330, 0.099, 0.000, 0.330

so the +-inf and -0.33 pattern results change with 'raw_wave' in yuqk.

When I run my v3.8 beta 2 compile and compare to yuqk without 
'raw_wave', I get the differences:

yuqk
----
Val(val("-inf")) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 1.000, 0.000, 0.000

v3.8 beta 2
-----------
Val(val("-inf")) = 0.000, 1.000, 0.000, 0.000, 0.000
Val(val("+inf")) = 0.000, 0.000, 0.000, 0.000, 0.000

Another issue potentially in play is that the official POV-Ray code had 
a small epsilon adder on the pattern return values meant to keep the 
values at 1.0 from snapping back to zero (some of the pattern 
implementations in POV-Ray proper defeated this code by doing their own 
clamping(*)). I don't recall the epsilon value used. The yuqk fork 
handles this 'essentially 1.0' condition with more care / precision.

(*) - I don't remember if gradient x was one of these. The yuqk code 
isn't clamping the gradient return values.

Bill P.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [429 days 2 hours and 2 minutes ago]

Sun, 16 Feb 2025 00:35:00 GMT

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

> Are you running yuqk?

Not at the moment.  Just straight 3.8.

> The triple 0.5 entries are not valid if you want to see all three
> values. Rather, perhaps:
>
>    [0.50-E rgb x]
>    [0.50   rgbt 1]
>    [0.50+E rgb y]
>
> With all 0.5s the middle color effectively doesn't exist in the map.

Well, that was part of the experiment, to see what happened.
0 and 1 work nicely.

It's the -inf that really has me puzzled!

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [429 days 2 hours and 45 minutes ago]

Sat, 15 Feb 2025 23:51:52 GMT

On 2/15/25 16:32, Bald Eagle wrote:
> Some useful things, plus a puzzling one to think about / decipher in source.

Are you running yuqk?

The triple 0.5 entries are not valid if you want to see all three 
values. Rather, perhaps:

   [0.50-E rgb x]
   [0.50   rgbt 1]
   [0.50+E rgb y]

With all 0.5s the middle color effectively doesn't exist in the map.

Bill P.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [429 days 5 hours and 2 minutes ago]

Sat, 15 Feb 2025 21:35:00 GMT

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

> While working on the glory feature that CR posted, it (re)occurred to me that
> having some sort of "flag" to jimmy function / color map behaviour would be a
> useful thing.
>
> I need to absolutely exclude certain inputs to my texture / color_map, and with
> pov-ray's value-wrapping, and real-valued function results, I find myself
> spending a lot of time trying to do clever things to use values to signify that
> I want to do things "off to the side" of what the main function is doing.
> Because I'm stuck using a mathematical function, not a macro or algorithm -
> which some languages refer to as "functions".
>
> What I'm wondering is if there's a (future) way to set the result of a function
> like select () to NAN, i, or some other "orthogonal placeholder" that a
> color_map would just "ignore" and maybe set to something like rgbft1.

So, an interesting idea occurred to me.
We can have discontinuous color_maps with duplicate entries specifying cusps.
So how do the values at those cusps get evaluated?

I designed a color_map and a function {pigment {}} to test this.

#declare Gradient =
pigment {
 gradient x
 color_map {
  [0.00 rgbt 1]
  [0.00 rgb 0]
  [0.33 rgb x]
  [0.50 rgb x]
  [0.50 rgbt 1]
  [0.50 rgb y]
  [0.66 rgb y]
  [1.00 rgb z]
  [1.00 rgbt 1]
 }
}

#declare fG = function {pigment {Gradient}}



Results:

Val(val("-inf")) = 0.000, 1.000, 0.000, 0.000, 0.000  [huh?]
Val(-0) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(0) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(+0) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(E) = 0.000, 0.000, 0.000, 0.000, 0.000
Val(0.5-E) = 1.000, 0.000, 0.000, 0.000, 0.000
Val(0.5) = 1.000, 0.000, 0.000, 0.000, 0.000
Val(0.5+E) = 0.000, 1.000, 0.000, 0.000, 0.000
Val(1-E) = 0.000, 0.000, 1.000, 0.000, 0.000
Val(-0+1) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(1) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(+0+1) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(val("nan")) = 1.000, 1.000, 1.000, 0.000, 1.000
Val(val("+inf")) = 1.000, 1.000, 1.000, 0.000, 1.000


Some useful things, plus a puzzling one to think about / decipher in source.

- BE

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [433 days 4 hours and 15 minutes ago]

Tue, 11 Feb 2025 22:22:20 GMT

On 2/11/25 11:17, jr wrote:
> hi,
> 
> kurtz le pirate <kur### [at] freefr> wrote:
>>
>> I think I'd have to re-run "make install" with my folder as the target,
>> but I can't see (or I didn't understand) how to do that.
> 
> I too installed yuqk in a convenient place.  write an email, I'd be happy to
> send you a build script and stuff.
> 
> 
> regards, jr.
> 

The script jr uses is good. (Thanks jr).

---

I'll quickly add for others who might see this thread, for a more 
permanent install you should not use the /tmp directory as I did in 
examples - for safety reasons. That directory is generally deleted by 
most unix/linux operating systems during the shutdown/reboot process.

Rather, create a directory somewhere under your $HOME directory where 
you do (aim) your 'make install's. For example, once, in your home 
directory execute the command:

mkdir yuqkBuilds

Then when you run the configuration command use:_a5c25dda

./configure -q COMPILED_BY=... --prefix=$HOME/yuqkBuilds/yuqk_a5c25dda

Later when you do 'make install' all the files will be copied for you 
into that --prefix specified directory. Most important for your issue, 
the 'povray' executable looks to the expected / configured install 
location  for that 'install-level' configuration file.

Lastly, it's very likely in using the yuqk fork, you will have multiple 
versions installed so a wrapper script like 'yuqk' is the way the 
'povray' executable is expected to be run / called.

All that said - there are many alternate methods to set things up. :-)

Bill P.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [433 days 9 hours and 57 minutes ago]

Tue, 11 Feb 2025 16:40:00 GMT

Damn.
I like that tree command!   :)

[jr] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [433 days 10 hours and 17 minutes ago]

Tue, 11 Feb 2025 16:20:00 GMT

hi,

kurtz le pirate <kur### [at] freefr> wrote:
>
> I think I'd have to re-run "make install" with my folder as the target,
> but I can't see (or I didn't understand) how to do that.

I too installed yuqk in a convenient place.  write an email, I'd be happy to
send you a build script and stuff.

regards, jr.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [433 days 10 hours and 28 minutes ago]

Tue, 11 Feb 2025 16:09:46 GMT

On 10/02/2025 19:25, kurtz le pirate wrote:
> 
> The hard part is over. I don't have time now. I'll continue later :) :)
> 


A little bit hs, sorry.

The program works. I have created a folder "yuqk_a5c25dda" in my $HOME 
folder. Files ares :


louis@Jammy:~/yuqk_a5c25dda$ tree
.
â”œâ”€â”€ bin
â”‚Â Â 
â””â”€â”€ povray
â”œâ”€â”€ etc
â”‚Â Â 
â””â”€â”€ povray
â”‚Â Â     
â””â”€â”€ 3.8
â”‚Â Â         
â”œâ”€â”€ povray.conf
â”‚Â Â         
â””â”€â”€ povray.ini
â””â”€â”€ share
     â”œâ”€â”€ doc
     â”‚Â Â 
â””â”€â”€ povray-3.8
     â”‚Â Â     
â”œâ”€â”€ html
     â”‚Â Â     
â””â”€â”€
NowShippedAsSeparate_DocAndAid_tarball
     â”œâ”€â”€ man
     â”‚Â Â 
â””â”€â”€ man1
     â”‚Â Â     
â””â”€â”€ povray_yuqk.1
     â””â”€â”€ povray-3.8
         â”œâ”€â”€ icons
         â”œâ”€â”€ include
         â”‚Â Â 
â”œâ”€â”€ arraycoupleddf3s.inc
         â”‚Â Â 
â”œâ”€â”€ arrays.inc
         â”‚Â Â 
â”œâ”€â”€ arraystatistics.inc
         â”‚Â Â 
â”œâ”€â”€ cfunctions.inc
         â”‚Â Â 
â”œâ”€â”€ crystal.ttf
         â”‚Â Â 
â”œâ”€â”€ cyrvetic.ttf
         â”‚Â Â 
â”œâ”€â”€ forkversion.inc
         â”‚Â Â 
â”œâ”€â”€ functions.inc
         â”‚Â Â 
â”œâ”€â”€ math.inc
         â”‚Â Â 
â”œâ”€â”€ munctions.inc
         â”‚Â Â 
â”œâ”€â”€ povlogo.ttf
         â”‚Â Â 
â”œâ”€â”€ rand.inc
         â”‚Â Â 
â”œâ”€â”€ setidtypes.inc
         â”‚Â Â 
â”œâ”€â”€ shapes.inc
         â”‚Â Â 
â”œâ”€â”€ strings.inc
         â”‚Â Â 
â”œâ”€â”€ timrom.ttf
         â”‚Â Â 
â”œâ”€â”€ transforms.inc
         â”‚Â Â 
â”œâ”€â”€ ttffonts.cat
         â”‚Â Â 
â”œâ”€â”€ vectoranalysis.inc
         â”‚Â Â 
â”œâ”€â”€ vectors.inc
         â”‚Â Â 
â””â”€â”€ version.inc
         â”œâ”€â”€ ini
         â”‚Â Â 
â””â”€â”€ povray.ini
         â”œâ”€â”€ scenes
         â”‚Â Â 
â”œâ”€â”€ biscuit.pov
         â”‚Â Â 
â”œâ”€â”€ fog
         â”‚Â Â 
â”‚Â Â 
â”œâ”€â”€ Bridge.inc
         â”‚Â Â 
â”‚Â Â 
â””â”€â”€ fog.pov
         â”‚Â Â 
â””â”€â”€ rtr_kla.pov
         â””â”€â”€ scripts
             â”œâ”€â”€ render_anim.sh
             â”œâ”€â”€ render_scene.sh
             â”œâ”€â”€ rerunpov.sh
             â””â”€â”€ runpov.sh


I add "~/yuqk_a5c25dda/bin:" in the PATH variable.



Asking the version for povray, i get :

povray: cannot open the system configuration file:
/tmp/yuqk_a5c25dda/etc/povray/3.8/povray.conf: No such file or directory
Persistence of Vision(tm) Ray Tracer    (see --license)
Copyright 1991-2025 Persistence of Vision Raytracer Pty. Ltd.
POV-Ray (yuqk) 3.8.0-x.yuqk_a5c25dda.unofficial
This is an unofficial version compiled by: louis
...
...

povray is still looking for the configuration file in the construction 
folder /tmp/yuqk_a5c25dda/...


I think I'd have to re-run "make install" with my folder as the target, 
but I can't see (or I didn't understand) how to do that.



Any help ?




-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [433 days 21 hours and 16 minutes ago]

Tue, 11 Feb 2025 05:21:16 GMT

On 2/10/25 18:59, Bald Eagle wrote:
> So, I just tested NAN and inf out of curiosity, and it seems they both default
> to zero in the color_map.

It should be the +-inf values work - so long as you use yuqk's raw_wave 
value pattern modifier (it's actually a pattern-value modifier bypass).

See attached scene file.

Bill P.

[William F Pokorny] Re: yuqk value distributions and color maps [433 days 21 hours and 21 minutes ago]

Tue, 11 Feb 2025 05:15:53 GMT

On 2/10/25 14:45, Bald Eagle wrote:
> Perhaps having some sort of inbuilt graphing calculator object {} would be nice
> to have - and maybe things like function {pigment{}} could get plugged in...
> Values for noise distributions

See histogram.pov shipped in the yuqk_DocAndAid_a5c25dda.tar.gz tarball.

<where unpacked>/yuqk_DocAndAid_a5c25dda/DocAidScenes/histogram.pov

Bill P.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 2 hours and 37 minutes ago]

Tue, 11 Feb 2025 00:00:00 GMT

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

> > What I'm wondering is if there's a (future) way to set the result of a function
> > like select () to NAN, i, or some other "orthogonal placeholder" that a
> > color_map would just "ignore" and maybe set to something like rgbft1.
>
> Interesting ideas as far as I understand what you want to do.
>
> The yuqk fork's pattern value wrapping is somewhat different / extended
> compared to POV-Ray - including some internal changes on the internal
> function / pattern map interface.
>
> We have some ability to 'jimmy map behavior' today in v3.8, but I think
> not quite what you are after.

So, I just tested NAN and inf out of curiosity, and it seems they both default
to zero in the color_map.

Bummer.  I suppose that's better than the render failing.

[Bald Eagle] Re: yuqk value distributions and color maps [434 days 6 hours and 27 minutes ago]

Mon, 10 Feb 2025 20:10:00 GMT

I was just ruminating some more on jimmying color maps, and your code for
utilizing complex numbers in yuqk:

Do you have a mechanism that "switches over" from real to imaginary upon taking
the sqrt of a negative number?

Math with imaginary numbers seems burdensome when one has to begin implementing
special-purpose functions at the user level.  Are there libraries that treat ALL
numbers as complex numbers, and only use special operations when the imaginary
component is nonzero?

I'm thinking that if your function VM were able to at least handle the
dot-notation of vector values (currently we have to pre-declare identifiers for
the separate vector components instead of simply using Vector.x) then you could
potentially use some nested select () to divert the math one way or the other.

[Bald Eagle] yuqk value distributions and color maps [434 days 6 hours and 47 minutes ago]

Mon, 10 Feb 2025 19:50:00 GMT

I was looking over some shader code for the glory rainbow effect, and was
impressed that there were some in-built distributions that could be applied
(bell curve, etc).

One of the things that has bothered me for a long time is the opaqueness of the
internally used values that POV-Ray uses to construct patterns.

It's been noticeable that certain patterns are skewed in their representation of
certain value ranges - and it takes a great deal of effort to visualize the
underlying value distributions, and then translate that to how it affects the
composition and color-mapping of the final pigment patterns.

https://news.povray.org/web.650c19af5bb87ec31f9dae3025979125%40news.povray.org

https://news.povray.org/povray.advanced-users/thread/%3Cweb.63ed381961f8e3fb1f9dae3025979125%40news.povray.org%3E/

https://news.povray.org/web.5ad4e0b9bb501a74c437ac910%40news.povray.org

It also seemed to me that there wasn't a very even distribution of random values
coming out of the PRNG.

I'm not sure if you (WFP) have any ideas for some sort of in-built tool to
somehow graph or otherwise represent and visualize the value distributions, or
if you think that such a thing is just going to be left as "an exercise for the
alert reader".

Perhaps having some sort of inbuilt graphing calculator object {} would be nice
to have - and maybe things like function {pigment{}} could get plugged in...
Values for noise distributions ....

It might help mightily in debugging current and future yuqk development work.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 8 hours and 12 minutes ago]

Mon, 10 Feb 2025 18:25:32 GMT

On 10/02/2025 17:44, William F Pokorny wrote:
> On 2/10/25 11:35, kurtz le pirate wrote:
>> But, on my 22.04 the command : 'sudo apt-get install openexr' say :
> 
> I believe the package you need is: libopenexr-dev
> 
> Bill P.

Finally, it's getting better. I had to make mistakes as always.

I redid these steps;
- ldconfig
- reboot
- ./configure
- make
- make check
- make install


I did see the little window with the "cookies".





For the moment, the executable is still in
"/tmp/yuqk_a5c25dda/bin"



------------------------
./povray --version say :

povray: cannot open the user configuration file:
/home/louis/.povray/3.8/povray.conf: No such file or directory
Persistence of Vision(tm) Ray Tracer    (see --license)
Copyright 1991-2025 Persistence of Vision Raytracer Pty. Ltd.
POV-Ray (yuqk) 3.8.0-x.yuqk_a5c25dda.unofficial
This is an unofficial version compiled by: louis

Built-in features:
   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
   Unsupported image formats: -

Compilation settings:
   Build architecture:  x86_64-pc-linux-gnu
   Built/Optimized for: x86_64-pc-linux-gnu
   Compiler vendor:     gnu
   Compiler version:    g++ 11.4.0
   Compiler flags:
     -pipe -w -fno-enforce-eh-specs -O2 -pthread


--------------------------
./povray --libraries say :

povray: cannot open the user configuration file:
/home/louis/.povray/3.8/povray.conf: No such file or directory

Boost 1.74, http://www.boost.org/

libjpeg 8.0, Copyright (C) 1991-1998, Thomas G. Lane.
Modified 2002-2009 by Guido Vollbeding.

OpenEXR 2.5.7 and IlmBase 2.5.7,
Copyright (c) 2002-2011 Industrial Light & Magic.

libpng version 1.6.37
Copyright (c) 2018-2019 Cosmin Truta
Copyright (c) 1998-2002,2004,2006-2018 Glenn Randers-Pehrson
Copyright (c) 1996-1997 Andreas Dilger
Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc.

LIBTIFF, Version 4.3.0
Copyright (c) 1988-1996 Sam Leffler
Copyright (c) 1991-1996 Silicon Graphics, Inc.

zlib 1.2.11, Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler




The hard part is over. I don't have time now. I'll continue later :) :)

ps : I took notes and orders throughout the installation. I'll format 
them and give them away if they help other mad people. LOL !!




-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 9 hours and 53 minutes ago]

Mon, 10 Feb 2025 16:44:36 GMT

On 2/10/25 11:35, kurtz le pirate wrote:
> But, on my 22.04 the command : 'sudo apt-get install openexr' say :

I believe the package you need is: libopenexr-dev

Bill P.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 9 hours and 59 minutes ago]

Mon, 10 Feb 2025 16:38:35 GMT

On 2/10/25 10:31, Bald Eagle wrote:
> Maybe some text could be sent to standard output stating that before your make
> script exits?
> 

Maybe. Let me review the INSTALL.txt file and think about it.

FWIW. On your question, I added a file called yuqk_wrapper_script to the 
shipped documentation for the next release.

...

> While working on the glory feature that CR posted, it (re)occurred to me that
> having some sort of "flag" to jimmy function / color map behaviour would be a
> useful thing.
> 
> I need to absolutely exclude certain inputs to my texture / color_map, and with
> pov-ray's value-wrapping, and real-valued function results, I find myself
> spending a lot of time trying to do clever things to use values to signify that
> I want to do things "off to the side" of what the main function is doing.
> Because I'm stuck using a mathematical function, not a macro or algorithm -
> which some languages refer to as "functions".
> 
> What I'm wondering is if there's a (future) way to set the result of a function
> like select () to NAN, i, or some other "orthogonal placeholder" that a
> color_map would just "ignore" and maybe set to something like rgbft1.

Interesting ideas as far as I understand what you want to do.

The yuqk fork's pattern value wrapping is somewhat different / extended 
compared to POV-Ray - including some internal changes on the internal 
function / pattern map interface.

We have some ability to 'jimmy map behavior' today in v3.8, but I think 
not quite what you are after.

I'll mention with function{}s you can hard code certain values. It's a 
feature I use to test maps. Rather than:

   function { Fn(...) }

code:

   function { 1/3 }

to see how a map behaves at that value. You can also use select to shift 
certain values which would normally fall within the defined map range, 
but I don't think you're asking for that.

There is too the ability to define the map indexes with functions. I 
suppose you could switch between maps that way. It would be a variation 
on code like:

#include "cfunctions.inc"
#declare Fn01 = function { pigment {
     image_map { "average_00_.jpg" ii_interpolate 2 }
     warp { repeat x flip x }
     warp { repeat y flip y }
     }
}
#declare R = 2;
#declare I = -2/4;
#declare EXP = cf_cmplx(R,I);
#declare PigMap = pigment_map {
     average // This necessary and enabled in yuqk fork
     [function { Fn01(cf_real(cf_pow(cf_cmplx(x,y),EXP)),
                      cf_imag(cf_pow(cf_cmplx(x,y),EXP)),0).red }
      color_map { [0 red 0] [1 red 3] }
     ]
     [function { Fn01(cf_real(cf_pow(cf_cmplx(x,y),EXP)),
                      cf_imag(cf_pow(cf_cmplx(x,y),EXP)),0).green }
      color_map { [0 green 0] [1 green 3] }
     ]
     [function { Fn01(cf_real(cf_pow(cf_cmplx(x,y),EXP)),
                      cf_imag(cf_pow(cf_cmplx(x,y),EXP)),0).blue }
      color_map { [0 blue 0] [1 blue 3] }
     ]
}
#declare Pig00 = pigment {
     average
     pigment_map { PigMap}
}

Bill P.

Aside : An idea / question I've had sitting in my head for some years is 
related to spectral rendering. One of the things spectral rendering 
works around is the color calculation biases within POV-Ray. In other 
words, I believe part of the better looking 'spectral result' comes from 
countering / balancing these calculation biases. I just don't know how 
big that 'due-calculation' portion of the result is.

What I'd like to try are ini / flag options which let the user 'rotate' 
a scene's color space. The resulting images would be normalized and 
combined for the final result a little like the current spectral rig. 
Someday, maybe... :-)

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 10 hours and 2 minutes ago]

Mon, 10 Feb 2025 16:35:38 GMT

On 10/02/2025 16:45, William F Pokorny wrote:
> On 2/10/25 10:12, kurtz le pirate wrote:
>> With ./configure, the compilation goes well but I get this message at 
>> the end:
>> --------------------
>> configure: WARNING: All program feature using the OpenEXR library are 
>> disabled
>>
>>
>> However, the OpenEXR package is (seems) installed. I don't know if I 
>> can continue if I can continue with the rest of the installation.
>>
> 
> The missing support only matters if you need to read or write .exr 
> images with your scenes.

OK, it's not mandatory for the time being.
So I will continue.

> In a terminal window what do you see with the commands:
> 
>  Â  pkg-config --print-errors OpenEXR
>  Â Â Â  ()
> 
>  Â  pkg-config --modversion OpenEXR
>  Â Â Â  (3.1.5)
> 
>  Â  pkg-config --cflags OpenEXR
>  Â Â Â  (-I/usr/include/OpenEXR -pthread
-I/usr/include/Imath)
> 
>  Â  pkg-config --libs OpenEXR
>  Â Â Â  (-lOpenEXR-3_1 -lOpenEXRUtil-3_1
-lOpenEXRCore-3_1
>  Â Â Â Â Â  -lIex-3_1
-lIlmThread-3_1 -lImath-3_1)

Same answer for the four orders:

Package OpenEXR was not found in the pkg-config search path.
Perhaps you should add the directory containing `OpenEXR.pc'
to the PKG_CONFIG_PATH environment variable
Package 'OpenEXR', required by 'virtual:world', not found

> What is within the ()s is what I see on my Ubuntu 24.04 machine.

But, on my 22.04 the command : 'sudo apt-get install openexr' say :

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
openexr is already the newest version (2.5.7-1). <<<<<<<<<<<<<<<
The following packages were automatically installed and are no longer 
required:
   libwpe-1.0-1 libwpebackend-fdo-1.0-1
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

;)

-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 10 hours and 52 minutes ago]

Mon, 10 Feb 2025 15:45:08 GMT

On 2/10/25 10:12, kurtz le pirate wrote:
> With ./configure, the compilation goes well but I get this message at 
> the end:
> --------------------
> configure: WARNING: All program feature using the OpenEXR library are 
> disabled
> 
> 
> However, the OpenEXR package is (seems) installed. I don't know if I can 
> continue if I can continue with the rest of the installation.
> 

The missing support only matters if you need to read or write .exr 
images with your scenes.

In a terminal window what do you see with the commands:

   pkg-config --print-errors OpenEXR
     ()

   pkg-config --modversion OpenEXR
     (3.1.5)

   pkg-config --cflags OpenEXR
     (-I/usr/include/OpenEXR -pthread -I/usr/include/Imath)

   pkg-config --libs OpenEXR
     (-lOpenEXR-3_1 -lOpenEXRUtil-3_1 -lOpenEXRCore-3_1
       -lIex-3_1 -lIlmThread-3_1 -lImath-3_1)

What is within the ()s is what I see on my Ubuntu 24.04 machine.

Bill P.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 11 hours and 2 minutes ago]

Mon, 10 Feb 2025 15:35:00 GMT

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

> Have you otherwise sorted out the cause yourself?

Yes.  It was a direct result of trying to use the wrong commit string.

> > ../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e
> >
> > when in fact the package I was trying to compile/install was
> > povray-3.8.0-x.yuqk_a5c25dda

> > it.
> >
>
> The expectation is that yuqk's 'povray' executable will be run using a
> wrapper script. There is an example script in the root directory of the
> unpacked source code called 'yuqk'.

Maybe some text could be sent to standard output stating that before your make
script exits?

> I hope my rambling of some help.

It gives me a better idea of how to follow along.
I still need to get back into the linux mindset, and have some sort of mental
picture regarding where things are stored, how to access them, etc.

There's a lot of chown, chmod, ./filename, unfamiliar select/copy/paste
touchpad/keystroke combos, etc. that I have to familiarize myself with to adopt
a better workflow.

While working on the glory feature that CR posted, it (re)occurred to me that
having some sort of "flag" to jimmy function / color map behaviour would be a
useful thing.

I need to absolutely exclude certain inputs to my texture / color_map, and with
pov-ray's value-wrapping, and real-valued function results, I find myself
spending a lot of time trying to do clever things to use values to signify that
I want to do things "off to the side" of what the main function is doing.
Because I'm stuck using a mathematical function, not a macro or algorithm -
which some languages refer to as "functions".

What I'm wondering is if there's a (future) way to set the result of a function
like select () to NAN, i, or some other "orthogonal placeholder" that a
color_map would just "ignore" and maybe set to something like rgbft1.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 11 hours and 25 minutes ago]

Mon, 10 Feb 2025 15:12:39 GMT

On 07/02/2025 06:15, William F Pokorny wrote:
> Please see the attached tarballs, previous announcements in this forum 
> and INSTALL.txt for suggestions on compiling and running via wrapper 
> script.
> 
> Note. The yuqk_DocAndAid_a5c25dda.tar.gz and 
> yuqk_Examples_a5c25dda.tar.gz files will be attached to a response to 
> this posting.
> 
> A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
> likely existing POV-Ray scenes will work without modification.
> 
> Note. Those using g++ compiler version 13 or later must add the compiler 
> flag -fno-finite-math-only, if using the flag -ffast-math.
> 
> Note. Those compiling to the c++20 (or later) standard must currently 
> use the -fno-char8_t compiler flag.
> 
> Bill P.

I'm also trying to install this latest version on my
ubuntu 22.04 LTS'vm.

With ./configure, the compilation goes well but I get this message at 
the end:
--------------------
configure: WARNING: All program feature using the OpenEXR library are 
disabled



However, the OpenEXR package is (seems) installed. I don't know if I can 
continue if I can continue with the rest of the installation.


One idea ?
Thanks





ps: don't forget that I'm a great linux beginner.




-- 
kurtz le pirate
compagnie de la banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [434 days 16 hours and 27 minutes ago]

Mon, 10 Feb 2025 10:10:35 GMT

On 2/9/25 09:52, Bald Eagle wrote:

Hi,

First - first, thanks for attempting to build the new yuqk fork release.

---

First, I think what jr suggested about missing headers is a probable 
cause. IIRC (probably not), someone else was missing usual x-windows 
libraries too somewhat recently, on trying to build and saw a similar issue.

Except my 'first' reaction is how did this invalid build state slip past 
the x-windows configure (autotools) code...

Do you still have your config.log file? Near the bottom do you see the 
lines:

#define HAVE_LIBSDL2 1

#define BUILTIN_XWIN_DISPLAY "enabled"

Have you otherwise sorted out the cause yourself?

I'm, vaguely aware the underlying x-windows (Xorg) system is slowly 
being changed to something called Wayland. When I next can, I'll spend 
some time digging around. Last I knew there were no linux distributions 
shipped with Wayland as the default (user have to switch to do it 
themselves), but maybe that has changed and with it something about the 
'effective' windowing build support with linux distributions.

As a near term fix, you can install the sdl2 development libraries (if 
you have not) and it should be if you can use '--without-x' when you 
configure and build with the SDL2 preview window support instead. The 
yuqk default is to build and run with X windows, but it will always 
enable the newest SDL* windowing library too as part of the build, if it 
is available (and the user hasn't set a configuration option to disable it).

You can also build and run with no preview window capability at all by 
disabling both X and SDL previews.

> So, I noticed in the installation instructions there is the command:
> 
> ../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e
> 
> when in fact the package I was trying to compile/install was
> povray-3.8.0-x.yuqk_a5c25dda
> 

Yeah, that's a bit confusing. Let me go clean it up for the next 
release. Ah, it's pervasive. I'll put it on the list to add something to 
yuqk's 'make dist' process to update it to the current commit string for 
each release.

> Once yuqk gets installed, I guess the program is still called povray, since the
> make check runs the following:
> 
> ../unix/povray +i./scenes/biscuit.pov -f +d -p +v +w320 +h240 +a0.3 +L./include
> 
> I'm guessing that for routine rendering, I can use alias to make something like
> "yuqk biscuit.pov"
> use the full path to yuqk povray and &1 to render whatever .pov file I throw at
> it.
> 

The expectation is that yuqk's 'povray' executable will be run using a 
wrapper script. There is an example script in the root directory of the 
unpacked source code called 'yuqk'. The internals of which are updated 
to point to your install location for the release prior to copying the 
script to you $HOME/bin directory, for example. You can also update that 
'yuqk' script in place as a way to quickly run without doing a 'make 
install'.

(Yep, I see too this another place where I should automatically update 
to the current release's commit string)

The yuqk fork is changing significantly release to release. The 
expectation is those using the yuqk fork will end up having many yuqk 
scripts in there $HOME/bin directory each pointing to a small install 
location of about 5MB.

I myself have: yuqk_3317dfc0, yuqk_9871ed6e and yuqk_a5c25dda wrapping 
builds / installs of the last three yuqk fork releases. I also have 
several development wrapper scripts pointing to different build 
configurations of development code at any given time (Something 
autotools supports well) - FWIW.

I hope my rambling of some help.

Bill P.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [435 days 11 hours and 42 minutes ago]

Sun, 9 Feb 2025 14:55:00 GMT

So, I noticed in the installation instructions there is the command:

../configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e

when in fact the package I was trying to compile/install was
povray-3.8.0-x.yuqk_a5c25dda

Once yuqk gets installed, I guess the program is still called povray, since the
make check runs the following:

../unix/povray +i./scenes/biscuit.pov -f +d -p +v +w320 +h240 +a0.3 +L./include

I'm guessing that for routine rendering, I can use alias to make something like
"yuqk biscuit.pov"
use the full path to yuqk povray and &1 to render whatever .pov file I throw at
it.

[jr] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [435 days 20 hours and 47 minutes ago]

Sun, 9 Feb 2025 05:50:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> doing make, and I get a lot of:
>
> /usr/bin/ld: disp_x11.cpp:(.text+0x2085): undefined reference to
> `XGetVisualInfo'
> ...
> any ideas?

guessing the header files for the various X libraries are not installed ?

also, see inbox.

regards, jr.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [435 days 22 hours and 52 minutes ago]

Sun, 9 Feb 2025 03:45:00 GMT

doing make, and I get a lot of:

/usr/bin/ld: disp_x11.cpp:(.text+0x2085): undefined reference to
`XGetVisualInfo'
/usr/bin/ld: disp_x11.cpp:(.text+0x2096): undefined reference to `XFree'
/usr/bin/ld: disp_x11.cpp:(.text+0x20b3): undefined reference to
`XCreateColormap'
/usr/bin/ld: disp_x11.cpp:(.text+0x2126): undefined reference to `XCreateWindow'
/usr/bin/ld: disp_x11.cpp:(.text+0x218b): undefined reference to
`XSetWMNormalHints'
/usr/bin/ld: disp_x11.cpp:(.text+0x21c5): undefined reference to `XSetClassHint'
/usr/bin/ld: disp_x11.cpp:(.text+0x21e7): undefined reference to
`XCreateBitmapFromData'
/usr/bin/ld: disp_x11.cpp:(.text+0x220c): undefined reference to
`XCreateBitmapFromData'
/usr/bin/ld: disp_x11.cpp:(.text+0x224a): undefined reference to `XSetWMHints'
/usr/bin/ld: disp_x11.cpp:(.text+0x2261): undefined reference to `XSetIconName'
/usr/bin/ld: disp_x11.cpp:(.text+0x2287): undefined reference to `XCreateGC'
/usr/bin/ld: disp_x11.cpp:(.text+0x22a0): undefined reference to `XSelectInput'
/usr/bin/ld: disp_x11.cpp:(.text+0x22b0): undefined reference to `XMapWindow'
/usr/bin/ld: disp_x11.cpp:(.text+0x22da): undefined reference to `XCreateImage'
/usr/bin/ld: disp_x11.cpp:(.text+0x2302): undefined reference to `XInitImage'
/usr/bin/ld: disp_x11.cpp:(.text+0x2410): undefined reference to `XPutImage'
/usr/bin/ld: disp_x11.cpp:(.text+0x2420): undefined reference to `XFlush'
/usr/bin/ld: disp_x11.cpp:(.text+0x2583): undefined reference to `XPutImage'

any ideas?

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [436 days 3 hours and 52 minutes ago]

Sat, 8 Feb 2025 22:45:00 GMT

installed a bunch of packages.

Needed to hammer on the libpng-dev thing

sudo apt install build-essential zlib1g-dev
cd
mkdir src
cd src
wget
https://ppa.launchpadcontent.net/linuxuprising/libpng12/ubuntu/pool/main/libp/libpng/libpng_1.2.54.orig.tar.xz
tar Jxfv libpng_1.2.54.orig.tar.xz
cd libpng-1.2.54
../configure
make
sudo make install
sudo ln -s /usr/local/lib/libpng12.so.0.54.0 /usr/lib/libpng12.so
sudo ln -s /usr/local/lib/libpng12.so.0.54.0 /usr/lib/libpng12.so.0

Then I installed libtiff-dev
and then everything was fine




===============================================================================
Configure POV-Ray (yuqk) version 3.8.0-x.yuqk_a5c25dda
===============================================================================

---------------
  Environment
---------------

------------
  Programs
------------

-------------------------------------------
  Attempt dump of compiler built-in specs
-------------------------------------------

-------------
  Libraries
-------------

-----------------------
  Language constructs
-----------------------

----------------------
  Language functions
----------------------

---------------------
  Compiling options
---------------------

---------------------------
  Floating Point Features
---------------------------

-------------
  Makefiles
-------------

--------------------------------------------------------
  Definitions setting POV-Ray (yuqk) run time messages
--------------------------------------------------------

===============================================================================
POV-Ray (yuqk) 3.8.0-x.yuqk_a5c25dda has been configured.
===============================================================================

See the file config.log for more detail.
See the file INSTALL.txt for more build options and information.

[Bald Eagle] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [436 days 8 hours and 12 minutes ago]

Sat, 8 Feb 2025 18:25:00 GMT

Installing on fairly fresh MINT install.
Looks like I need to install certain libraries first.

===============================================================================
Configure POV-Ray (yuqk) version 3.8.0-x.yuqk_a5c25dda
===============================================================================

---------------
  Environment
---------------

------------
  Programs
------------

-------------------------------------------
  Attempt dump of compiler built-in specs
-------------------------------------------

-------------
  Libraries
-------------
configure: error: cannot find a suitable PNG library

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. a5c25dda [437 days 21 hours and 19 minutes ago]

Fri, 7 Feb 2025 05:18:16 GMT

On 2/7/25 00:15, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_a5c25dda.tar.gz and 
> yuqk_Examples_a5c25dda.tar.gz files will be attached to a response to 
> this posting.

Bill P.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. a5c25dda [437 days 21 hours and 22 minutes ago]

Fri, 7 Feb 2025 05:15:49 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_a5c25dda.tar.gz and 
yuqk_Examples_a5c25dda.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. Those using g++ compiler version 13 or later must add the compiler 
flag -fno-finite-math-only, if using the flag -ffast-math.

Note. Those compiling to the c++20 (or later) standard must currently 
use the -fno-char8_t compiler flag.

Bill P.

---
---------------- povray-3.8.0-x.yuqk_a5c25dda.tar.gz  February 06, 2025
yuqk R18 v0.6.12.0

Removed a dynamic_cast in render time bump_map image value access code, 
which significantly improved performance.

Added the inbuilt function f_lcm() accepting up to six integer values 
plus a use count integer with values 1 thru 6.

Added the inbuilt function f_gcd() accepting up to three integer values 
and a match value. Returns the greatest common denominator found when 
the match value is 0. Otherwise it returns 1 when the gcd is equal to 
the match value and 0.0 otherwise.

Deleted the f_leopard pattern. The leopard pattern itself was recently 
updated so as to be much more flexible making the inbuilt function obsolete.

Moved the minimum C++ compiler standard to c++17 (has long been c++11).

Added the inbuilt function f_round() which itself is a wrap of 
std::lround().

Deleted the f_onion pattern. The onion pattern itself was recently 
updated so as to be much more flexible making the inbuilt function obsolete.

---
Re-worked the image_indexed_textures{} feature so it more reliably works 
with image formats supporting channel depths > 8 bits or channel values 
 >1.0.

- Texture list entry 0 is always the default background / unmapped 
region texture. Further, rather than wrap when palette registers/indexes 
exceed the number of textures in the list, yuqk maps these also to the 0 
texture entry.

- Adding support for color channel depths > 8 bits by specifying texture 
list of longer than 256 entries. (The 0.0..1.0 red channel multiplier 
becomes 65535.0 rather than always 255.0)

- High dynamic range images, which often have .red or .grey values > 1.0 
in typical use, can exploit this support by using the .red or .grey 
values directly as index values into the texture list.

- Removed a dynamic_cast in render time image value access code, which 
significantly improved performance.

- Additional parse time checks for valid map types, etc.

- Added warp{} parsing support missing always since warp{}s added.

- Rather than casting map image float values to integers, yuqk now 
rounds using std::lround() which makes interpolations more usable / stable.

- Negative .red / .grey channel values, which have never been handled 
explicitly, are now treated as equivalent positive index values after 
rounding.

- Fixed bugs in imageutil.cpp's InterpolateBicubic() and Interp() where 
the code by numerical noise was sometimes flipped into an index 
calculated mode.

---

Renamed the material_map{} feature image_indexed_textures{} - which is 
what it always has been. Confusion was created when later support for a 
material{} feature was added. The material{} feature encapsulates 
texture{}s and interior{}s via identifier references.

---

Completed the move of image input modifier keywords to ones with 'ii_' 
prefixes. These are keywords used with the bump_map{}, image_map{}, 
image_pattern{} and material_map{} blocks / features of POV-Ray to 
modify how the image is mapped to surfaces or shapes.

The complete list of 'ii_' prefixed keywords is: ii_all, ii_filter, 
ii_interpolate, ii_map_type, ii_offset, ii_once, ii_repeat, ii_transmit, 
ii_use_alpha, ii_use_color, ii_use_colour and ii_use_index. The 
'ii_offset' and 'ii_repeat' had previously been created where there was 
long existing, but undocumented, image input features called offset and 
repeat in the POV-Ray source code.

The following keywords with respect to the R17 release state have been 
renamed so as to have the 'ii_' prefix: all, interpolate, map_type, 
once, use_color, use_colour and use_index. In other words, un-prefixed 
forms of these keywords no longer exist.

The keywords 'ii_filter' and 'ii_transmit' now exist alongside the 
keywords 'filter' and 'transmit' which are still used with the channel, 
dot access syntax for color vectors and with little used, old style, 
color definitions.

The keyword 'ii_use_alpha' now exist alongside the keyword 'use_alpha' 
used within the finish{} block.

---

[jr] Re: Updated yuqk tarballs for Unix/Linux. 9871ed6e [483 days 16 hours and 47 minutes ago]

Mon, 23 Dec 2024 09:50:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/22/24 23:54, jr wrote:
> > builds, then an error while running 'make check' (see attached). ...
> No worries. I appreciate your testing the release.
>
> The error you're getting is a standard early exit by a user. It's one I
> can duplicate if I hit 'q' to cancel shortly after the preview window
> opens and before it closes while running 'make check' from a terminal
> window. (I do not see the "Script done" message which I suppose is
> coming from your build script).
> Are you able to render the biscuit.pov scene in the ...
> directory, directly?
>  yuqk biscuit.pov

thanks, invoking 'yuqk scenes/biscuit.pov' in the build directory works.  will
now  need to find out where the key event could have come from (I'd switched to
a different desktop while the build script ran); the "Script done" you (too)
should see when running eg 'script -c ./somescript the_log'.  sorry about the ..
excitement ;-).

regards, jr.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 9871ed6e [483 days 20 hours and 45 minutes ago]

Mon, 23 Dec 2024 05:51:52 GMT

On 12/22/24 23:54, jr wrote:
> builds, then an error while running 'make check' (see attached).  nothing,
> deprecated warnings for exr + tiff libs aside, "untoward" in the build log,
> afaict.  sorry.

No worries. I appreciate your testing the release.

The error you're getting is a standard early exit by a user. It's one I 
can duplicate if I hit 'q' to cancel shortly after the preview window 
opens and before it closes while running 'make check' from a terminal 
window. (I do not see the "Script done" message which I suppose is 
coming from your build script).

Are you able to render the biscuit.pov scene in the

	<build directory>/scenes

directory, directly?

	yuqk biscuit.pov

If not that could you try:

	yuqk biscuit.pov --preview text

and if your build includes an sdl1.2 or sdl2.0 preview option:

	yuqk biscuit.pov --preview sdl

Bill P.

[jr] Re: Updated yuqk tarballs for Unix/Linux. 9871ed6e [483 days 21 hours and 42 minutes ago]

Mon, 23 Dec 2024 04:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarballs, previous announcements in this forum
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
>
> Note. The yuqk_DocAndAid_9871ed6e.tar.gz and
> yuqk_Examples_9871ed6e.tar.gz files will be attached to a response to
> this posting.

builds, then an error while running 'make check' (see attached).  nothing,
deprecated warnings for exr + tiff libs aside, "untoward" in the build log,
afaict.  sorry.

regards, jr.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 9871ed6e [490 days 16 hours and 44 minutes ago]

Mon, 16 Dec 2024 09:53:46 GMT

On 12/16/24 04:50, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_9871ed6e.tar.gz and 
> yuqk_Examples_9871ed6e.tar.gz files will be attached to a response to 
> this posting.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. 9871ed6e [490 days 16 hours and 47 minutes ago]

Mon, 16 Dec 2024 09:50:47 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_9871ed6e.tar.gz and 
yuqk_Examples_9871ed6e.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. Those using g++ compiler version 13 or later must add the compiler 
flag -fno-finite-math-only, if using the flag -ffast-math.

Note. Those compiling to the c++20 (or later) standard must currently 
use the -fno-char8_t compiler flag.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_9871ed6e.tar.gz  December 16, 2024
yuqk R17 v0.6.11.0

Added potential{} value pattern support to the polygon object.

Revised the potential{} pattern mechanism to generically support the 
keywords ip_type, ip_offset and ip_mode in addition to the existing 
ip_threshold. The thinking is there's no reason to limit a shape's 
potential pattern support to reproducing the 3D shapes as a value fields 
suited to isosurace function use.  The parsing for all these generic 
potential{} pattern keywords was moved within the potential{} block 
which is more consistent - especially within the yuqk fork.

Updated the f_dturbulence() function so it, like the new f_dnoise() 
function has three additional seed/translationm x,y,z values for the 
noise field which are independent of the 'working x,y,z' values.

Better aligned the f_turbulence() and f_dturbulence() parameter limits.

Added an inbuilt function called f_dnoise() which provides direct access 
to the source code's DNoise() function.

Fix for the polygon shape parsing restoring the checking that any z 
values passed are identical for all vertex locations. Several other 
degenerate shape results are now hard parsing errors rather than quietly 
marking polygons as ivalid. When marked invalid they are quietly ignored 
during rendering - leaving users lost as to what might be wrong.

---

The Scene Description Language function vturbulence() updated to support 
the DTturbulence() scaling factor added to the yuqk fork. I had delayed 
this update because I was undecided about updating its parameter order. 
In POV-Ray and its documentation the order given for 'turbulence' 
settings is almost universally:

     <magnitude> --> octaves --> omega --> lambda (--> scale (yuqk))

The vturbulence() function was implemented switching the positions of 
octaves and lamda. In yuqk, the vturbulence() parameter order is now:

     vturbulence(octaves,omega,lambda,scale,3d point in space)

---
All keywords in yuqk working internal to pattern or perturbation code 
now use the 'ip_' prefix; Excepting those specifically related to 
turbulence, which have for some time used the internal turbulence prefix 
of 'it_'.

Renamed the slope value pattern's 'altitude and 'point_at' keywords 
'ip_altitude' and 'ip_point_at'.

Renamed the density_file value pattern's 'interpolate' keyword 
'ip_interpolate'.

Involving the scalar value patterns: 'julia', 'magnet', 'mandel' and 
'pavement'. Moved 'exponent' to 'ip_exponent'. Created the internal 
pattern (ip_) keywords: ip_exterior, ip_interior, ip_pattern, ip_sides, 
ip_tiles.  Deleted the keywords: 'exterior', 'number_of_sides', 
'number_of_tiles'.

Fix for wrinkles pattern sensitivity to small x,y,z components at the 
evaluation point.

Adding 'ip_form', 'ip_offset' and 'ip_raw_return' as options for the for 
the scalar value 'onion' pattern. When no options are used the behavior 
is unchanged.

Fixing / adding it_scale support to the patterns 'marble', 'spiral1' and 
'spiral2'. This was an oversight when the general it_scale capability 
was added to turbulence in yuqk.

The leopard pattern re-written to support a new ip_form keyword for much 
more control over how the pattern is generated. Results are identical if 
the ip_form vector is left at the default of <1,1,1>. Where one or two 
vector components are zero, the return values are more reliably in the 0 
to 1 range (The pattern still squares internally so the value field is 
not linear).

Moved the 'color image creation by function' internal storage to RGBFT 
32 bit floats supporting positive and negative values. It had long 
supported only positive 16 bit values limiting it's usefulness.

Updating few internal pattern strings to user facing names for better 
error messages.

The control0, control1, flip, hi and lo pattern / perturbation keywords 
have been renamed as ip_c0, ip_c1, ip_flip, ip_hi and ip_lo. The 
control0 and control1 keywords exist in official POV-Ray releases for 
quilted. The keywords flip, hi and lo were ones new to yuqk. The yuqk 
perturbations / patterns affected are: quilted, grooved, tiled and waves.

The global_settings{} noise_generator option was removed. It was never 
truly global! The old set up added overhead for all patterns. It left a 
situation where sharing SDL was exposed to differences in behavior, any 
time the user sharing did not lock all the noise generator use. It 
limited flexibility with options like fog{} and irid{}.

Created a new 'ip_noise_generator' keyword for the patterns / 
perturbations: agate, bozo, bumps, dents, granite, marble, noise_cubed, 
spiral1, spiral2 and wrinkles. Made changes so the two remaining uses of 
'noise_generator' now set values local to 'fog{}' and 'irid{}'. The 
patterns and features mentioned here are the only ones ever affected by 
'noise_generator' settings, global or not.

Changed potential pattern 'threshold' keyword to 'ip_threshold'.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 3317dfc0 [516 days 20 hours and 55 minutes ago]

Wed, 20 Nov 2024 05:42:27 GMT

On 11/19/24 19:26, William F Pokorny wrote:
> On 11/4/24 01:27, William F Pokorny wrote:
>> Please see the attached tarballs
> 
> For the record.
> 
> There are problem(s) in this release (and my development space) with 
> 'some' normal{} use. I now have one case where the normals just don't 
> work and a second which core dumps.
> 
> I've not got a clue what change(s) might have tripped this behavior. I 
> don't believe I touched anything related to normals for this last 
> release. :-(
> 

Attached is a patched source code tarball. After compiling,  if one runs 
the version.pov file shipped with yuqk it will show v0.6.10.1 rather 
than v0.6.10.0.

I was away from POV-Ray / yuqk coding and play for more than two months 
after the early July yuqk release. I forgotten I'd slapped at some code 
faster than using a dynamic_pointer_cast for possible normal blend maps 
on every Perturb_Normal() call. The code wasn't supposed to be released 
yet, but I let it slip by...

In my development space now trying another method. This time using a 
'hard assert' in BOTH the performance compile and debug compile. The 
debug compile of v0.6.10.0 had an assert which immediately pointed to 
the problem for scenes showing issues, but the assert was only in the 
debug compile. FWIW.

Bill P.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 3317dfc0 [517 days 2 hours and 11 minutes ago]

Wed, 20 Nov 2024 00:26:37 GMT

On 11/4/24 01:27, William F Pokorny wrote:
> Please see the attached tarballs

For the record.

There are problem(s) in this release (and my development space) with 
'some' normal{} use. I now have one case where the normals just don't 
work and a second which core dumps.

I've not got a clue what change(s) might have tripped this behavior. I 
don't believe I touched anything related to normals for this last 
release. :-(

Bill P.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 3317dfc0 [530 days 21 hours and 56 minutes ago]

Wed, 6 Nov 2024 04:41:46 GMT

On 11/5/24 12:15, jr wrote:
> thanks.  builds and 'make check' ok, on Slackware 15.

Thank you for testing it! :-)

Bill P.

[jr] Re: Updated yuqk tarballs for Unix/Linux. 3317dfc0 [531 days 9 hours and 17 minutes ago]

Tue, 5 Nov 2024 17:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarballs, previous announcements in this forum
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
>
> Note. The yuqk_DocAndAid_3317dfc0.tar.gz and
> yuqk_Examples_3317dfc0.tar.gz files will be attached to a response to
> this posting.

thanks.  builds and 'make check' ok, on Slackware 15.


regards, jr.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 3317dfc0 [532 days 20 hours and 7 minutes ago]

Mon, 4 Nov 2024 06:30:01 GMT

On 11/4/24 01:27, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_3317dfc0.tar.gz and 
> yuqk_Examples_3317dfc0.tar.gz files will be attached to a response to 
> this posting.

Files attached to this post.

Bill P.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. 3317dfc0 [532 days 20 hours and 10 minutes ago]

Mon, 4 Nov 2024 06:27:35 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_3317dfc0.tar.gz and 
yuqk_Examples_3317dfc0.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. Those using g++ compiler version 13 or later must add the compiler 
flag -fno-finite-math-only, if using the flag -ffast-math.

Note. Those compiling to the c++20 (or later) standard must currently 
use the -fno-char8_t compiler flag.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_e6e987ab.tar.gz  Novemeber 04, 2024
yuqk R16 v0.6.10.0

Moved dens_object pattern 'exponent' keyword to 'ip_exponent'. Moved 
dens_object and hard_object pattern keywords: 'radius', 
'recursion_limit' and 'samples' to 'ip_radius', 'ip_recursion_limit' and 
'ip_samples', respectively.

Added the inbuilt function f_popnrm_rnoise(). Fast, normal-ish fit 
random noise values based upon x,y,z coordinates and a user seed value.

The dependency on boost/functional/hash/hash.hpp (boost::hash_combine() 
and boost::hash()) has been removed.

The crackle scalar value pattern largely re-written to address thread 
cache collisions and a small collection of issues and bugs. Though the 
re-write is both faster and slower, for the traditional scenes at small 
scale downs (large crackle cells) it tends to be slower. Of note the 
dependency the ip_solid option had on the noise generators was removed. 
The new caching is currently not optimal as it is set up to experiment 
with larger cell counts around the center cell.

Added ip_cache, ip_exponent and ip_seed features to the crackle pattern.

Updates to support OpenEXR 3.0 changes. Code adapted from that 
implemented by Ton van den Broek (TonVanDenBroek) and Christoph Lipka 
(c-lipka) as the merged github pull #423 against the official v3.8 beta 
2 release. Note. Input and output remain at 16 bits / half floats rather 
than 32 bits.

Changes to INSTALL.txt suggested performance build flags which include 
-ffast-math to also include -fno-finite-math-only given the g++ version 
13 compiler turns on finite-math-only and many g++ implementations of 
finite-math-only causes various errors and fails while rendering. Some 
of these fails might not be immediately apparent.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. e6e987ab [657 days 10 hours and 55 minutes ago]

Tue, 2 Jul 2024 15:42:15 GMT

On 7/2/24 11:39, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_e6e987ab.tar.gz and 
> yuqk_Examples_e6e987ab.tar.gz files will be attached to a response to 
> this posting.

Files attached to this post.

Bill P.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. e6e987ab [657 days 10 hours and 58 minutes ago]

Tue, 2 Jul 2024 15:39:21 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_e6e987ab.tar.gz and 
yuqk_Examples_e6e987ab.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Note. The crackle pattern and facets perturbation caching is disabled in 
this release due bugs with multiple uses within each thread. Performance 
is significantly degraded in scenes where they are used.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_e6e987ab.tar.gz  July 02, 2024
yuqk R15 v0.6.9.0

Attempting an implementation of constant identifiers / macro parameters. 
They are indicated by using leading 'ro_' character in the name. See 
documentation for the feature in the file: 
.../ThinkingAloud/ro_ReadOnlyIdentifiers.txt

Updated parser error messages related to floating, defined identifiers 
to something hopefully a little more helpful.

Fixed photons bug with inverse squared lighting. Credit to Cousin Ricky.

Disabled the 'crackle' and 'facets' cache in a simple, but rather 
expensive way. It was found there are cache collision issues when >1 
cache or >1 facets patterns run in the same thread. A better 
amelioration is in the works.

Renamed the long implemented but undocumented 'offset' and 'repeat' 
keywords.  The are now part of the image input (ii_) prefixed options as 
used in the bump_map{}, image_map{}, image_pattern{} and material_map{} 
blocks. New names are 'ii_offset' and 'ii_repeat'.

The crackle pattern's ip_offset value is now a simple adder just ahead 
of the patterns value return. This much more useable than the attempted 
- and partly broken normalization of the offset value to the current metric.

Added the keyword options 'ip_raw_return <boolean>' and 'ip_strength <3D 
vector>' to the crackle pattern. The 'ip_raw_return' setting controls 
whether value clamping to 0-1 range is done or not. The 'ip_strength' 
vector controls how vigorously noise is applied to the center point of 
each cube for the pseudo random seed locations for the crackle pattern.

All pattern related uses of 'type' were changed to 'ip_type' (internal 
pattern / internal perturbation prefix). This affects: 'bevy', 'facets', 
'lean', 'noise_cubed', 'spatial', and 'seedfi'. The 'bevy' normal 
perturbation pattern being a developer's sandbox.

The pavement pattern's 'form' changed to 'ip_form'. The 'form' keyword 
was deleted.

The crackle pattern's 'form', 'metric', 'offset', 'repeat' and 'solid' 
keywords have been changed to new 'ip_form' ,'ip_metric', 'ip_offset', 
'ip_repeat' and 'ip_solid' keywords. The 'metric' and 'solid' keywords 
were deleted.

The facets normal{} only pattern was updated. A new keyword was 
introduced in 'type' was implemented to make explicit which of the 
current two forms of facets is to be used. The 'coords' keyword was 
deleted; It was always equivalent to the more general normal{} block 
'bump_size' keyword when valid.  The undocumented 'metric' support and 
keyword has been move to a new 'ip_metric' keyword. The last remaining 
use of the keyword 'size' in facets was changed to 'ip_size'. The 'size' 
keyword was deleted.

Added concrete, lean, niln and spatial normal{} block perturbation patterns.

The soft_object{} pattern's 'spacing' and 'strength' keywords are now 
'ip_spacing' and 'ip_strength', respectively.

The brick discrete pattern was updated. The 'brick_size' and 'mortar' 
keywords being replaced by 'ip_size' and 'ip_spacing', respectively. The 
'ip_size' 3D vector now represents the actual brick size less the 
spacing / mortar between bricks. The 'ip_spacing' is now a 3D vector 
specifying the space between bricks in x,y and z. Lastly, one or more of 
the values can be set to 0.0, indicating the brick is infinite (no 
mortar) along that axis; It should be easier to avoid having surfaces 
end up all or partly in mortar.

Adding an inbuilt f_catenary() function aimed at being a general 
foundation upon which more can be built.

Fixed clang++ builds where vm inbuilt functions were making use of 
constexpr functions only implemented in g++.

Patched gnu build for dynamic CPU optimization. Code was for some years 
broken on at least some x86 CPU types. We were not always using the AMD 
/ Intel hand optimized code where we could.

Updated INSTALL.txt related to clang++ build configure script options.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 2f941611 [714 days 19 hours and 53 minutes ago]

Mon, 6 May 2024 06:44:18 GMT

On 5/6/24 02:39, William F Pokorny wrote:
> Note. The yuqk_DocAndAid_2f941611.tar.gz and 
> yuqk_Examples_2f941611.tar.gz files will be attached to a response to 
> this posting.

Tarballs attached.

Bill P.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. 2f941611 [714 days 19 hours and 58 minutes ago]

Mon, 6 May 2024 06:39:49 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

Note. The yuqk_DocAndAid_2f941611.tar.gz and 
yuqk_Examples_2f941611.tar.gz files will be attached to a response to 
this posting.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

Added the following vm inbuilt functions: f_2x_f32_vadd, f_2x_f32_vaddc, 
f_2x_f32_vdiv, f_2x_f32_vdivc, f_2x_f32_vdot, f_2x_f32_vinv, 
f_2x_f32_vlength, f_2x_f32_vlength_sqr, f_2x_f32_vmul, f_2x_f32_vmulc, 
f_2x_f32_vnormalize, f_2x_f32_vsub, f_2x_f32_vsubc, f_3x_f21_vadd, 
f_3x_f21_vaddc, f_3x_f21_vcross, f_3x_f21_vdiv, f_3x_f21_vdivc, 
f_3x_f21_vdot, f_3x_f21_vinv, f_3x_f21_vlength, f_3x_f21_vlength_sqr, 
f_3x_f21_vmul, f_3x_f21_vmulc, f_3x_f21_vnormalize, f_3x_f21_vsub and 
f_3x_f21_vsubc.

Removed a back door feature allowing library paths to be specified 
without flag or option settings so long as the 'floating' path ended in 
a path separator ('/' on unix/linux). For example:

     povray /tmp/RTR/ test.pov

would add '/tmp/RTR/' to the library paths including the trailing '/' 
triggering the back door. The feature existed despite the trailing '/', 
by some code and our documentation, being illegal..?

The ini file extension defaulting is now restricted as compared to 
official POV-Ray releases. Unknown strings on the command line or in ini 
files will no longer default to attempts to read an ini file with a 
suffix variations of the string. The feature exposed users to confusing 
results. Floating ini files on the command line or within ini files must 
now be specified with the '.ini' extension. For example, use:

     yuqk +l$HOME/myinifiles scene.ini

over:

     yuqk +l$HOME/myinifiles scene

Any ini files specified with the +-ini flag / include_ini= option may 
still be specified without the '.ini' extension.

Fix for issue where only the first specified library path was searched 
for ini files not in the current directory - or fully specified with 
+-ini or include_ini.

Fix where errors inside ini files specified with +-ini<filename> or 
include_ini=<filename> were being ignored (error state was overwritten).

Fixes for a number of obscure issues while parsing .pov and .ini file 
specifications.

The rainbow{} feature removed. This includes the removal of following 
keywords specifically dedicated to it: 'arc_angle', 'falloff_angle' and 
'width'. The rainbow feature related uses of the following keywords have 
also been removed: 'angle', 'direction', 'distance', 'jitter' and 'up'.

[jr] Re: Updated yuqk tarballs for Unix/Linux. ec0430bd [748 days 9 hours and 27 minutes ago]

Tue, 2 Apr 2024 17:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached ...

thanks.  install + simple test went ok.

@Kurtz

attached a simple build script, to add to your collection :-); the prefix
directory and ownership etc need adjusting.  hth.


regards, jr.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. ec0430bd [749 days 8 hours and 39 minutes ago]

Mon, 1 Apr 2024 17:58:01 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_ec0430bd.tar.gz  April 01, 2024
yuqk R13 v0.6.7.0

Updated +-mi flag / max_image_buffer_memory ini option to allow zero 
argument.  An intuitive way to turn the buffering off to save memory.

Added antialias_gamma=1.0 (+ag1) and antialias_threshold=0 fast path 
code to sampling method 3. The fast paths already existed in methods 1 
and 2. (The color channel gamma corrections ahead of the threshold test 
are relatively expensive)

Fixed a divide by zero bug in AA sampling method 3 where we end up with 
a single pixel within a thread rendering block.

The reporting of pixels and samples per pixel made substantially cleaner 
for Anti-Aliasing methods 1 and 2.

The upper limit for Anti-Aliasing threshold increased to 1e35 from 1.0. 
Though the upper limit long at 1.0 (or a step under), the difference for 
methods 1 & 2 always could be as much as four even where rgbt channel 
values all with a 0-1 range. Folks often exceed the 0-1 range - 
especially today with HDR environments / real light intensity renders.

The extended command line flag checking now returns errors in a way more 
aligned with existing command line checking, rather than throwing an 
exception.

Correcting typo in the ini name for the new Anti-Aliasing Min Depth 
option, 'Antialias_Min_Depth'. Also renaming the +-rm flag form of the 
command to +-rd.  I was reminded - the hard way - that 'rm' is a 
dangerous command in any Linux / Unix environment...

Added a +-ini<filename> command line flag as a pairing to the long 
implemented but, never documented include_ini=<filename> ini file option.

Changed the create_continue_trace_log=on|off / +-cc default to off.

Changed verbose output (verbose=on|off, +v, -v) default to false.

Implemented additional command line flag checking for previously missed 
specification errors.

A minor bug fix for +ec / enc_column and +er / end_row options when the 
starting values defaulted.

Removed small, bounding adder around font glyphs as used in the text{} 
object.  The change dates back to yuqk release R8, v0.6.2.0. It was 
causing problems where constructed scene elements depended upon the 
returned min_extent(), max_extent() vectors of passed text{} objects or 
IDs (per jr). The adder fixed clipping issues in very rare cases; user 
can always manually bound those, if need be.

[William F Pokorny] Re: yuqk tarballs for Unix/Linux - Ubuntu [751 days 14 hours and 47 minutes ago]

Sat, 30 Mar 2024 11:50:18 GMT

On 3/30/24 06:52, kurtz le pirate wrote:
> So as not to have the same problems as the other times, I made a script
> that checks the presence of the libraries and their versions.

Yes, a script like this is a good idea. I don't have one myself. Truth 
is, that I've just been upgrading my Ubuntu for a long time. I've not 
installed the necessary packages to compile POV-Ray/yuqk from scratch 
for many years. :-)

---

I'm concerned with your list of packages:

NeededPackages=("libboost-dev" "libboost-date-time-dev"
"libboost-thread-dev" "zlib1g-dev" "libpng12-dev" "libjpeg8-dev"
"libtiff5-dev" "libopenexr-dev")

This list looks like the old one recommended in some of the POV-Ray 
shipped Unix files (v3.7?). It's part of the documentation on my update 
it someday for yuqk list.

First up, I see again libboost-dev over libboost-all-dev? At the moment 
I am myself unsure of the precise list of boost packages needed to 
compile. For yuqk and the v4.0 POV-Ray development branch I don't 
believe libboost-date-time-dev or libboost-thread-dev are any longer 
needed (For sure yuqk is using thread library built into C++).

The secondary issue is that you are specifying particular versions of 
some of the libraries. Unless problems crop up, we should use the 
versions tested to align with the larger Linux / Unix version (Ubuntu 
22.04) release. You do this by specifying generic names for: libpng-dev, 
libjpg-dev, libtiff-dev.

The third issue is you should probably add "libsdl2-dev" which is the 
newer version of the Simple Direct media Layer (SDL/SDmL)) library(a). 
It offers a second preview display option (and it will pull in X11 stuff 
if need be).

(a) - Yes, there is a version number there! That library is a partial 
exception to the don't specify the library version rule for reasons 
related to how SDmL development broke hard with version 1.2. It's a 
generic specification for versions 2.0+.

Bill P.

Aside: Ubuntu itself offers already set up, starter VM environments for 
various releases of Ubuntu. I used it years ago to create a bunch of 
statically linked POV-Ray version at particular git commits over time. 
Unfortunately, at the moment, I cannot remember enough about it to get 
anyone started with it.

[kurtz le pirate] yuqk tarballs for Unix/Linux - Ubuntu [751 days 15 hours and 45 minutes ago]

Sat, 30 Mar 2024 10:52:42 GMT

Hello,

My VMWare has crashed and I've lost my vm :(
That's all right. I'm making another one.

So as not to have the same problems as the other times, I made a script
that checks the presence of the libraries and their versions.

If it helps...
--------------------------------------------------------------------------------
#!/bin/bash
clear
echo -e "\n\n--- Needed packages for povray yuqk\n"
NeededPackages=("libboost-dev" "libboost-date-time-dev"
"libboost-thread-dev" "zlib1g-dev" "libpng12-dev" "libjpeg8-dev"
"libtiff5-dev" "libopenexr-dev")

for p in ${NeededPackages[@]}; do
  dpkg -l $p >/dev/null 2>&1
  # is here ?
  if [ $? -ne 0 ]
    then
    echo -e ">> \"$p\" not installed or issue retrieving informations.\n"
  # need upgrade ?
  else
    NeedUpgrade=$(apt-get -s upgrade -u | egrep -c "^Conf $p |^Inst $p ")
    if [ $NeedUpgrade -gt 0 ]
    then
      echo -e ">> \"$p\" need an upgrade.\n"
    else
      echo -e ">> \"$p\" is up to date.\n"
    fi
  fi
done
echo -e "end...\n"
--------------------------------------------------------------------------------

ps: I'm an Ubuntu beginner, so please bear with me.


-- 
Kurtz le pirate
Compagnie de la Banquise

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. 169416... [760 days 16 hours and 2 minutes ago]

Thu, 21 Mar 2024 10:35:13 GMT

On 20/03/2024 20:20, jr wrote:
> 
>> ...
>> last messages on terminal :
> most got lost, containing accents :-(.
> 


hum... hum...

Big differences between nntp and http.
I made screenshots of both interfaces:





-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: Updated yuqk tarballs for Unix/Linux. 169416... [761 days 7 hours and 12 minutes ago]

Wed, 20 Mar 2024 19:25:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> finally, rebuilding the cache with ldconfig solved the problem.

super.  glad you're "up and running".

> ...
> last messages on terminal :

most got lost, containing accents :-(.

> ...
> As everything is ok, i run make check
> I can see the rendering of an image which also closes when finished.
> I don't know where it's saved (or not).

you wrote you're "new to Linux".  recommend getting to know 'script(1)'.  for
instance when you render a scene, you can "record" all terminal i/o, eg:
  $ script -c 'povray myscene.pov' log-file
and you have a full "transcript" in the 'log-file'.

regards, jr.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. 169416... [761 days 9 hours and 46 minutes ago]

Wed, 20 Mar 2024 16:51:34 GMT

On 20/03/2024 09:53, jr wrote:
> 
> strange that the linker does not "see" the X11 libraries.  the linker works off
> a set of cached directories, if you still have the same problem, have a look at
> '/etc/ld.so.conf' and the files in '/etc/ld.so.conf.d/', are your library paths
> listed ?  (if yes, the cache may need refreshing ( run 'ldconfig')).

everything looks good for '/etc/ld.so.conf' and the files in
'/etc/ld.so.conf.d/'. Library paths are present.

> also, wondering what (exact) arguments were given to './configure'.

in accordance with 'INSTALL.txt' doc :

./configure -q COMPILED_BY="name" CXXFLAGS="-O2" --prefix=/tmp/yuqk_427af17e

no strange argument.

finally, rebuilding the cache with ldconfig solved the problem.
(I should have used -v to track what was going on).

so :
running ldconfig, then ./configure, then make, then after a long long
list of messages : no error :)

last messages on terminal :
make[2] : on quitte le répertoire
« /home/doubled/build_yuqk/povray-3.8.0-x.yuqk_16941651/unix »
make[2] : on entre dans le répertoire
« /home/doubled/build_yuqk/povray-3.8.0-x.yuqk_16941651 »
cat ./povray.ini.in | sed
"s,__POVLIBDIR__,/tmp/yuqk_427af17e/share/povray-3.8,g" > ./povray.ini
make[2] : on quitte le répertoire
« /home/doubled/build_yuqk/povray-3.8.0-x.yuqk_16941651 »
make[1] : on quitte le répertoire
« /home/doubled/build_yuqk/povray-3.8.0-x.yuqk_16941651 »
(on quitte le répertoire -> we leave the directory) ;)

As everything is ok, i run make check
I can see the rendering of an image which also closes when finished.
I don't know where it's saved (or not).

Then run make install.
No error :)

I think all these problems come from the fact that I made a
'./configure' and 'make' with the missing X11 library. Necessary links
and cache to the right shared libraries have become corrupted.

**THANKS** for all Jr.

-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: Updated yuqk tarballs for Unix/Linux. 169416... [761 days 17 hours and 42 minutes ago]

Wed, 20 Mar 2024 08:55:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> On 18/03/2024 21:26, William F Pokorny wrote:
> > Can you list libX11 files?  ls -l libX11*
> >
> > On my Ubuntu machine I see:
> > ...

> Yes, exactly the same thing

strange that the linker does not "see" the X11 libraries.  the linker works off
a set of cached directories, if you still have the same problem, have a look at
'/etc/ld.so.conf' and the files in '/etc/ld.so.conf.d/', are your library paths
listed ?  (if yes, the cache may need refreshing ( run 'ldconfig')).

also, wondering what (exact) arguments were given to './configure'.

regards, jr.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. 169416... [762 days 12 hours and 4 minutes ago]

Tue, 19 Mar 2024 14:33:30 GMT

On 18/03/2024 21:26, William F Pokorny wrote:

> 
> Can you list libX11 files?  ls -l libX11*
> 
> On my Ubuntu machine I see:
> 
> -rw-r--r-- 1 root root 2209016 Oct  2 15:13 libX11.a
> lrwxrwxrwx 1 root root      15 Oct  2 15:13 libX11.so -> libX11.so.6.4.0
> lrwxrwxrwx 1 root root      15 Oct  2 15:13 libX11.so.6 -> libX11.so.6.4.0
> -rw-r--r-- 1 root root 1306280 Oct  2 15:13 libX11.so.6.4.0
> lrwxrwxrwx 1 root root      19 Oct  2 15:13 libX11-xcb.so.1 -> 
> libX11-xcb.so.1.0.0
> -rw-r--r-- 1 root root   14048 Oct  2 15:13 libX11-xcb.so.1.0.0

Yes, exactly the same thing


> Aside: In official versions of POV-Ray there is a file in the unix 
> directory with more information on the packages to install, but it's out 
> of date and I've never gotten around to updating it. So, the yuqk 
> tarball doesn't ship with it. Maybe I should bump up the priority there. 


I'm going to check the unix distribution to see if there's any
additional information.


> FWIW, it should be you can configure with '--without-x' and get a text 
> only version of the 'povray' executable which the yuqk script wraps. It 
> will then have no preview display as the Simple Direct Media 'sdl' 
> options (like the x11 preview display) also need x11 to work... 'make 
> check' should run - and if so, you would be able to render to output 
> image files.


I'll take a look at it too...



-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 169416... [763 days 6 hours and 10 minutes ago]

Mon, 18 Mar 2024 20:26:59 GMT

On 3/18/24 12:26, kurtz le pirate wrote:
> Now it's the x11 library which causes issues:(
> 
> ...
> ...
> /usr/bin/ldÂ : disp_x11.cpp:(.text+0x2b8)Â :
rÃ©fÃ©rence indÃ©finie vers
> Â«Â XDestroyWindowÂ Â»
> /usr/bin/ldÂ : disp_x11.cpp:(.text+0x2c8)Â :
rÃ©fÃ©rence indÃ©finie vers
> Â«Â XFreeColormapÂ Â»
> /usr/bin/ldÂ : disp_x11.cpp:(.text+0x2d8)Â :
rÃ©fÃ©rence indÃ©finie vers
> Â«Â XFreeGCÂ Â»
> /usr/bin/ldÂ : disp_x11.cpp:(.text+0x2e4)Â :
rÃ©fÃ©rence indÃ©finie vers
> Â«Â XCloseDisplayÂ Â»
> /usr/bin/ldÂ : disp_x11.oÂ : dans la fonction
>
Â«Â pov_frontend::UnixX11Display::UpdateScreen(bool)Â Â»Â :
> ...
> ...

I'm still learning how linux works too... :-)

If you cd to the directory:

/lib/x86_64-linux-gnu or /usr/lib/x86_64-linux-gnu/

Can you list libX11 files?  ls -l libX11*

On my Ubuntu machine I see:

-rw-r--r-- 1 root root 2209016 Oct  2 15:13 libX11.a
lrwxrwxrwx 1 root root      15 Oct  2 15:13 libX11.so -> libX11.so.6.4.0
lrwxrwxrwx 1 root root      15 Oct  2 15:13 libX11.so.6 -> libX11.so.6.4.0
-rw-r--r-- 1 root root 1306280 Oct  2 15:13 libX11.so.6.4.0
lrwxrwxrwx 1 root root      19 Oct  2 15:13 libX11-xcb.so.1 -> 
libX11-xcb.so.1.0.0
-rw-r--r-- 1 root root   14048 Oct  2 15:13 libX11-xcb.so.1.0.0

If you don't see these, maybe your libx11 files are located somewhere 
else? If you can find that location, you can add a link time flag to 
point to it.

Aside: In official versions of POV-Ray there is a file in the unix 
directory with more information on the packages to install, but it's out 
of date and I've never gotten around to updating it. So, the yuqk 
tarball doesn't ship with it. Maybe I should bump up the priority there. 

FWIW, it should be you can configure with '--without-x' and get a text 
only version of the 'povray' executable which the yuqk script wraps. It 
will then have no preview display as the Simple Direct Media 'sdl' 
options (like the x11 preview display) also need x11 to work... 'make 
check' should run - and if so, you would be able to render to output 
image files.

Bill P.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. 169416... [763 days 10 hours and 10 minutes ago]

Mon, 18 Mar 2024 16:26:55 GMT

On 17/03/2024 19:10, William F Pokorny wrote:
> On 3/17/24 10:43, kurtz le pirate wrote:
>> "function.hpp" does not
existï»¿ï»¿ï»¿ï»¿
anywhere.
>> What do you think?
> 
> I'll assume your './configure ...' command ran OK since you are running 
> make.

Yes it is.


> Did you install the libboost-dev or libboost-all-dev Ubuntu package?
> You want the latter one - though in total it install much more than 
> POV-Ray absolutely needs.

libboost-all-dev has fixed the problem.
Now it's the x11 library which causes issues:(

...
...
/usr/bin/ldÂ : disp_x11.cpp:(.text+0x2b8)Â :
rÃ©fÃ©rence indÃ©finie vers
Â«Â XDestroyWindowÂ Â»
/usr/bin/ldÂ : disp_x11.cpp:(.text+0x2c8)Â :
rÃ©fÃ©rence indÃ©finie vers
Â«Â XFreeColormapÂ Â»
/usr/bin/ldÂ : disp_x11.cpp:(.text+0x2d8)Â :
rÃ©fÃ©rence indÃ©finie vers
Â«Â XFreeGCÂ Â»
/usr/bin/ldÂ : disp_x11.cpp:(.text+0x2e4)Â :
rÃ©fÃ©rence indÃ©finie vers
Â«Â XCloseDisplayÂ Â»
/usr/bin/ldÂ : disp_x11.oÂ : dans la fonction
Â«Â pov_frontend::UnixX11Display::UpdateScreen(bool)Â Â»Â :
...
...



I'm still researching and learning how Linux works.




-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 169416... [764 days 8 hours and 27 minutes ago]

Sun, 17 Mar 2024 18:10:46 GMT

On 3/17/24 10:43, kurtz le pirate wrote:
> "function.hpp" does not
existï»¿ï»¿ï»¿ï»¿
anywhere.
> What do you think?

I'll assume your './configure ...' command ran OK since you are running 
make.

Did you install the libboost-dev or libboost-all-dev Ubuntu package?
You want the latter one - though in total it install much more than 
POV-Ray absolutely needs.

Bill P.

[jr] Re: Updated yuqk tarballs for Unix/Linux. 169416... [764 days 11 hours and 2 minutes ago]

Sun, 17 Mar 2024 15:35:00 GMT

hi,

kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> I made my ubuntu's vm, add somes essantials package and libray.
> Now, I get this error when run "make" :
> ---
> make[2] : on entre dans le répertoire
> « /home/doubled/build_yuqk/povray-3.8.0-x.yuqk_16941651/source »
>   CXX      backend/bounding/boundingtask.o
> In file included from ../source/backend/bounding/boundingtask.h:58,
>                  from backend/bounding/boundingtask.cpp:39:
> ../source/backend/support/task.h:53:10: fatal error: boost/function.hpp:
> Aucun fichier ou dossier de ce nom
>    53 | #include <boost/function.hpp>
>       |          ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> ---
> "function.hpp" does not exist anywhere.
> What do you think?

I think you're the "victim" of the Debian / Ubuntu "bright minds" -- who split
every software, at least, into three "packages".  "-devel" typically for the
headers, and documentation too needs to be requested, "-doc" I think.  (you'll
need headers for the other to-be-linked-to libraries too)


regards, jr.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. 169416... [764 days 11 hours and 54 minutes ago]

Sun, 17 Mar 2024 14:43:31 GMT

On 16/03/2024 19:40, William F Pokorny wrote:
> On 3/16/24 11:15, kurtz le pirate wrote:
>> Do you think your yuqk is compatible with JellyFish (Ubuntu 22.4.4) ?
> 
> Hi.
> 
> Yes. My primary development machine is running Ubuntu 22.4.4 too.  :-)
> 
> Bill P.
> 

Great !!!

I made my ubuntu's vm, add somes essantials package and libray.
Now, I get this error when run "make" :


---
make[2]Â : on entre dans le rÃ©pertoire
Â«Â /home/doubled/build_yuqk/povray-3.8.0-x.yuqk_16941651/sourceÂ Â»
  CXX      backend/bounding/boundingtask.o
In file included from ../source/backend/bounding/boundingtask.h:58,
                 from backend/bounding/boundingtask.cpp:39:
../source/backend/support/task.h:53:10: fatal error: boost/function.hpp:
Aucun fichier ou dossier de ce nom
   53 | #include <boost/function.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
---

"function.hpp" does not
existï»¿ï»¿ï»¿ï»¿
anywhere.
What do you think?





-- 
Kurtz le pirate
Compagnie de la Banquise

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 16941651 [765 days 7 hours and 56 minutes ago]

Sat, 16 Mar 2024 18:40:58 GMT

On 3/16/24 11:15, kurtz le pirate wrote:
> Do you think your yuqk is compatible with JellyFish (Ubuntu 22.4.4) ?

Hi.

Yes. My primary development machine is running Ubuntu 22.4.4 too.  :-)

Bill P.

[kurtz le pirate] Re: Updated yuqk tarballs for Unix/Linux. 16941651 [765 days 11 hours and 22 minutes ago]

Sat, 16 Mar 2024 15:15:15 GMT

On 05/03/2024 22:20, William F Pokorny wrote:
> Please see the attached tarballs, previous announcements in this forum 
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
> 
> A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
> likely existing POV-Ray scenes will work without modification.

Hi Bill,

Do you think your yuqk is compatible with JellyFish (Ubuntu 22.4.4) ?






-- 
Kurtz le pirate
Compagnie de la Banquise

[jr] Re: Updated yuqk tarballs for Unix/Linux. 16941651 [773 days 22 hours and 32 minutes ago]

Fri, 8 Mar 2024 04:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> With this release, most of the work was not feature or bug related.
> Rather, more with the build process and documentation.

caught an outdated bit, I think.


> If the build.log is from your new machine, I'd be interested in looking
> over a copy of it.

done.


regards, jr.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 16941651 [774 days 5 hours and 47 minutes ago]

Thu, 7 Mar 2024 20:50:34 GMT

On 3/7/24 07:23, jr wrote:
> thanks, install just finished.  fwiw, 'doc/html/' is empty ?  also, I see you're
> "cleaning up" the build process, can send the 'build.log' if interested.

Cool!

Yes, that empty doc/html directory is hanging around because I have an 
idea I'll eventually put something meaningful in it again (POV-Ray / 
yuqk links). Today, all the yuqk documentation I have together comes in 
that separate tarball.

With this release, most of the work was not feature or bug related. 
Rather, more with the build process and documentation.

If the build.log is from your new machine, I'd be interested in looking 
over a copy of it.

Bill P.

[jr] Re: Updated yuqk tarballs for Unix/Linux. 16941651 [774 days 14 hours and 12 minutes ago]

Thu, 7 Mar 2024 12:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarballs, previous announcements in this forum
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
> ...

thanks, install just finished.  fwiw, 'doc/html/' is empty ?  also, I see you're
"cleaning up" the build process, can send the 'build.log' if interested.

regards, jr.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. 16941651 [776 days 5 hours and 16 minutes ago]

Tue, 5 Mar 2024 21:21:18 GMT

Please see the attached tarballs, previous announcements in this forum 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_16941651.tar.gz  March 05, 2024
yuqk R12 v0.6.6.0

Fixed defaulting bugs with ripples and waves. Bugs were in the 
defaulting of the ip_scale & ip_fade_distance where only one of the two 
'extended options' was specified. Bugs existed since the original 
re-write of the four code implementations in early 2023.

Fixed bugs in options directing / echoing output streams to files.  The 
ini file / command line options fixed were: all_file, debug_file, 
fatal_file, render_file and statistic_file. Bugs, in some form, exist 
back to at least v3.1 (per Thorsten).

Added two additional shell out string substitutions in %d and %e. Where 
%d substitutes the directory in which the scene file exists and %e which 
substitutes the output image file extension.

Fixed bugs related to the shell out string substitutions '%%', '%s', 
'%h' and '%w' - which exist in official versions of POV-Ray too, v3.7 
onward.

Fixed command line flag parsing for flags having only a single character 
following the '+' or '-' and the space ahead of the trailing flag is 
missing.  For example, '-v+w700', was not parsed correctly for either 
flag - or reported as an error.  The bug exist in all code v3.8 onward 
(probably v3.7 too, but not tested).

Limiting povms assert()s in vfe to debug compiles. The performance gain 
running the shipped rtr_kla.pov scene with day-to-day compile was 0.70%.

Restored support for user configurations files (povray.conf, povray.ini) 
in $HOME/.povray/3.8 and similar directories. However, 'make install' 
still, does not create or update files in that directory to avoid 
collisions with official releases. As part of this update, yuqk's 
existing POVCON environment variable when set will ignore any 
$HOME/.povray/3.8/povray.conf file for whatever povray.conf file POVCON 
points too. The POVINI variables continues to work in a, now, similar 
way. See updated INSTALL.txt for more information.

Warning and error messages related to ini file and command-line parsing 
cleaned up a little more.

The default image size was changed to 320 x 240.

Changes to version defaulting so that the fully supported yuqk version 
(3.8) is defaulted during the ini / flag phase prior to the parser 
starting - if a version not otherwise specified by ini version= / flag 
+mv setting. The return to this approach fixes a set of standing issues 
related to not setting the default at the ini / flag stage. Further, the 
#version directive use while parsing a scene becomes necessary only 
where changes in version defaults or parsing behaviour is needed. It's 
still a good idea to indicate a scenes expected major POV-Ray version 
with a #version directive at the beginning of a scene.

Fixed issue with version defaults initialization. In yuqk the issue 
would not have been seen where the version was explicitly set to 3.8.

[Kenneth] Re: Updated yuqk tarballs for Unix/Linux. 427af17e [812 days 22 hours and 2 minutes ago]

Mon, 29 Jan 2024 04:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I ran the bug down to something sitting in v3.8 onward (perhaps older
> code too - I didn't check)...
>
> Attached is an image...


THANK YOU for doing such a thorough series of tests-- "above and beyond the call
of duty"! I really appreciate it.
>
> The bottom row is a repeat on the left for v3.8 beta 2, but I have made
> edits to your scene file to define a user default texture and make
> explicit it is the base for derived textures below. This amounts to
> replacing the default{} with:
>
> #declare DfltTxtr = texture { finish{ambient 1 emission 0 diffuse 0} }
> [snip]

That's a useful suggestion, thank you again for coming up with it! (I do recall
that you mentioned such changes, in one of your recent threads.) So, I decided
to eliminate my #default statement and add your edits...and everything still
works fine in v3.7 and 3.8 beta 1. I have attached the edited test scene, in
case you want to run a 'sanity check' to see if the results are still OK in your
fork.
>
> Aside: Your test case triggers the 'always full depth' method 3 bug
> still sitting in v3.8 beta 2...
>
> the following command:
>
>    p380b2 test.pov +w300 +h300 +a0.005 +am3 +ac0.90     +r5
>
> runs 400% slower.

Wow! Luckily for me, my object-slicing code will not make use of AA-- for
technical reasons having to do with that 3D SLICER medical app that I am using
for my POV-ray-to-STL 3-D-printing scheme (which is now almost ready to be
posted!)

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 427af17e [813 days 5 hours and 38 minutes ago]

Sun, 28 Jan 2024 20:59:30 GMT

On 1/28/24 11:30, Kenneth wrote:
> When I finally found a combination that worked, I settled on
> that...without running even*more*  possible(?) tests.

Yes, when testing POV-Ray the test combinations tend to explode. You can 
never cover it all. Permutations - like Bald Eagles recent image! :-)

I ran the bug down to something sitting in v3.8 onward (perhaps older 
code too - I didn't check). See:

https://news.povray.org/povray.beta-test/thread/%3C65b6ba93%241%40news.povray.org%3E/

Attached is an image. The left column are the results I see for v3.8 
beta 2. The right column what I see with yuqk (R11 and my working version)

The top row shows the four combinations as you posted them. The results 
match. In the just released yuqk R11, the default{} mechanism still exists.

The middle row shows both v3.8 beta 2 and yuqk (R12 working code) 
without the default{} block. Yuqk being different on the right is how I 
caught the bug up top. With that bug fixed the result again match. (The 
fixed result is not shown).

The bottom row is a repeat on the left for v3.8 beta 2, but I have made 
edits to your scene file to define a user default texture and make 
explicit it is the base for derived textures below. This amounts to 
replacing the default{} with:

#declare DfltTxtr = texture { finish{ambient 1 emission 0 diffuse 0} }

And below that changing :

texture{pigment{rgb 1}}
     and
pigment{OBJ_COLOR_}

to become:

texture{ DfltTxtr pigment{rgb 1} }
     and
texture{ DfltTxtr pigment{OBJ_COLOR_} }

Bill P.

Aside: Your test case triggers the 'always full depth' method 3 bug 
still sitting in v3.8 beta 2.

Even when I force a minimum number of samples and use big jitter with 
the recent yuqk release code using:

//   test 1  off                                   ****     *****
   yuqk test.pov   +w300 +h300 +a0.005 +am3 +ac0.90 +rm2 +r5 +j1.1

the following command:

   p380b2 test.pov +w300 +h300 +a0.005 +am3 +ac0.90     +r5

runs 400% slower. Results are of course good with both commands.

[Kenneth] Re: Updated yuqk tarballs for Unix/Linux. 427af17e [813 days 10 hours and 2 minutes ago]

Sun, 28 Jan 2024 16:35:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/27/24 06:27, Kenneth wrote:
> > would you mind running it in your current yuqk
> > fork?
>
> FYI. I did see your post. Thanks for the great test case. :-)
>
> Your code turned up a bug which I've been chasing since yesterday. I
> thought I'd nailed it a minute ago. Alas, not yet.
>
> I need to do some real life stuff for a bit. I'll post more when I've
> finally run the bug down.
>
No problem; thanks for taking the time to test it! You will probably notice that
the code has a mix of full texture statements plus 'naked' finish blocks. This
combination was what I had to come up with to get the results I needed (and to
take into account some slight differences between v3.7 vs 3.8 beta 1). The mix
may not be *the* ideal arrangement, as I had to experiment with a lot of
permutations. When I finally found a combination that worked, I settled on
that...without running even *more* possible(?) tests. ;-)

It could be that a few minor changes to my code's texture/finish mix would
eliminate your own bug *and* still make the result correct and consistent across
versions; I don't know.

[William F Pokorny] Re: Updated yuqk tarballs for Unix/Linux. 427af17e [813 days 13 hours and 32 minutes ago]

Sun, 28 Jan 2024 13:04:59 GMT

On 1/27/24 06:27, Kenneth wrote:
> would you mind running it in your current yuqk
> fork?

FYI. I did see your post. Thanks for the great test case. :-)

Your code turned up a bug which I've been chasing since yesterday. I 
thought I'd nailed it a minute ago. Alas, not yet.

I need to do some real life stuff for a bit. I'll post more when I've
finally run the bug down.

Bill P.

[Kenneth] Re: Updated yuqk tarballs for Unix/Linux. 427af17e [814 days 15 hours and 7 minutes ago]

Sat, 27 Jan 2024 11:30:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Fixed case with cutaway_textures in difference{} block where if first
> shape was not textured, it was being left with no texture during the
> rendering phase.  Results in such cases now align with intersection -
> and difference{} is really implemented as an intersection with all but
> the first object inverted.
>

[Running Windows 10]
I am currently working on an elaborate 'object-slicing' scene that makes use of
cutaway_textures and a #default finish{...} statement. I have attached a
simplified version of the scene; would you mind running it in your current yuqk
fork? I would be curious to know if the scene produces what I see, given your
updates to cutaway_textures (and possibly both the specified #default behavior
as well as your current behind-the-scenes #defaults).

It requires a *square* render, at any resolution you choose. I designed  the
various textures and finishes-- and the #default finish-- after experimenting to
find the best combinations; I hope they still work correctly in your
fork...especially the un-textured intersection box. On my end, the results are
consistent in both official v3.7.0 and 3.8 beta 1.

There are 2 switches in the scene , with 4 possible permutations. This is what I
see:

#declare WHICH_TEST_ = 1;
#declare USE_CUTAWAY_TEXTURES_ = off;
a totally white object inside a rectangular red box, against black

#declare WHICH_TEST_ = 1;
#declare USE_CUTAWAY_TEXTURES_ = on;
a yellow and blue object (with a slight red tint), inside a rectangular red box,
against black

#declare WHICH_TEST_ = 2;
#declare USE_CUTAWAY_TEXTURES_ = off;
a totally white object against black

#declare WHICH_TEST_ = 2;
#declare USE_CUTAWAY_TEXTURES_ = on;
a yellow and blue object against black

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. 427af17e [817 days 9 hours and 25 minutes ago]

Wed, 24 Jan 2024 17:12:34 GMT

Please see the attached tarballs and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

---------------- povray-3.8.0-x.yuqk_427af17e.tar.gz  January 24, 2024
yuqk R11 v0.6.5.0

The 'optional' keyword use has been restricted to macro parameters. As 
explanation the error message on such use is currently:

"The application of 'optional' keyword ahead of other than macro 
parameters is not presently allowed. This partly due the parser 
currently not always forcing closing semicolons when they are in fact 
required. Such missing semicolons are often only caught as errors when 
later identifiers are seen as undefined. The 'optional' keyword can hide 
these sorts of errors making results and debugging very confusing and 
difficult.

Further, the 'optional' keyword opens up ways for the wrong, identically 
named, elsewhere defined, identifiers to later be picked up during 
parsing.  It's undecided whether the more general 'optional' use will 
again be allowed."

Parser updates aimed at making situations involving undefined identifier 
errors, easier to understand. In particular, more often where the 
identifier name(s) are known, they are now included as part of the 
parser's error message(s).

Enabled big jitter for method 3 as well as methods 1 and 2, but as 
method 3 always randomly samples over the full 2d pixel, the jitter 
value acts as a sampling range multiplier when specified. Values like 
+j1.1 would slightly bleed sampling into adjacent pixels with method 3.

Moved Antialias methods 1 & 2 to the stochastic random number generator 
method 3 already uses. Also enabled Stochastic_Seed=n / +SSn for methods 
1 & 2 so the jitter-ing is mostly repeatable render to render.

Added Antialias_Min_Depth=n ini / +RMn flag options for antialias 
methods 2 and 3(a). It can be thought of as a way to implement initial 
non-adaptive AA sampling - better at resolving detail - prior to the 
adaptive AA. The option was added to method 1 as well, but there the min 
depth is used (if > 0) whenever the flat sub-sampling would normally be 
skipped due the current pixel not meeting the threshold test relative to 
the adjacent left and top pixels.  In other words, when using the min 
depth option with method 1 the pixel sub-sampling will toggle between 
two flat sub-sampling counts set by +RMn and +Rn, respectively.

Fixed case with cutaway_textures in difference{} block where if first 
shape was not textured, it was being left with no texture during the 
rendering phase.  Results in such cases now align with intersection - 
and difference{} is really implemented as an intersection with all but 
the first object inverted.

Relaxed smooth_triangle degeneracy treatment. Smooth triangles 
considered degenerate due the specified normals will no longer disappear 
due the setting of the shape's degenerate flag. The warning messages 
from the parser are still issued.

It was the case previously where users specified +sc1 and +ec1, or +sr1 
and +er1, the options would be ignored and all columns and/or rows would 
be rendered. These particular 1 and 1 specifications now work. Further, 
the additional checking suggested by Ryan Binns in github issue 312 was 
adopted - addressing all parts of issue 312.

Now flag vector tuples without trailing semicolon. The vector tuple / 
batch / list assignments of the vector form have always needed closing 
semicolons to stop falls into mid directive streams resulting in quietly 
corrupted parsing results.

Fixed bug in empty parentheses handing.

[jr] Re: Updated yuqk tarballs for Unix/Linux. b0c8c689 [901 days 15 hours and 47 minutes ago]

Wed, 1 Nov 2023 10:50:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarballs and previous announcements in this fora
> and INSTALL.txt for suggestions on compiling and running via wrapper script.

sorry to read about the hassle you were having.

> A reminder the yuqk fork is not POV-Ray. As time passes, it's less
> likely existing POV-Ray scenes will work without modification.

thanks.  hope to put together an email in the coming days re that.



regards, jr.

[William F Pokorny] Updated yuqk tarballs for Unix/Linux. b0c8c689 [903 days 9 hours and 11 minutes ago]

Mon, 30 Oct 2023 17:26:23 GMT

Please see the attached tarballs and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the yuqk fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

----------- povray-3.8.0-x.yuqk_b0c8c689.tar.gz  October 30, 2023
yuqk R10 v0.6.4.0

Renamed this fork of POV-Ray on finding the old name now collides with 
an apparently popular adult web site. Functionally, the change is mostly 
transparent to the end user except for a few things like the shipped 
wrapper script name was changed to 'yuqk'.

In my head, the yuqk fork name is an acronym for, "Yet Unknown Quality 
Kaleidoscope" with a varying comma placement (not shown). I'm 
pronouncing it like the English word, yuck.

The julia_fractal shape removed which includes the removal of following 
keywords specifically dedicated to it: 'cube', 'hypercomplex', 
'julia_fractal', 'max_iteration', 'precision', 'pwr', 'quaternion', 
'reciprocal' and 'slice'.

The julia_fractal related, secondary, specialized uses of the following 
keywords have also been removed: 'acos', 'acosh', 'asin', 'asinh', 
'atan', 'atanh', 'cos', 'cosh', 'exp', 'ln', 'sin', 'sinh', 'sqr', 'tan' 
and 'tanh'.

Added parse check for duplicate macro parameter names. The macro 
definition '#macro ABC(_a,_b,_a) ... #end' will now be considered in 
error due the second use of the '_a' parameter name.

The 'component' keyword support in the blob{} was removed. It's been 
obsolete for ages.

The 'deprecated' keyword support for identifiers removed. Always 
relatively expensive code for something almost never used. Further, 
there were bugs (not sorted) around local versus declare directive use 
and the existing deprecated support.

Fixed a number of parsing issues related to the 'global' and 'local' 
pseudo dictionaries maintained by the parser.

Added internal bitwise functions to rotate bits left or right in 
f_64x_ui1_rol() and f_64x_ui1_ror().

Official releases of POV-Ray have always multiplied the caustic exponent 
value a user specifies by 45.0 internally. The yuqk fork removed it, as 
the multiplier just makes it harder to understand and control the 
internal std::pow function used in shaded regions to create the faked 
effect.

Added a blend_mode 5 option which is similar to the new option 4 found 
for the first time in the previous release - except it peaks in the 
middle of the interval instead of at both ends.

[William F Pokorny] Updated povr tarballs for Unix/Linux. 1755021c [926 days 4 hours and 51 minutes ago]

Sat, 7 Oct 2023 21:46:00 GMT

Please see the attached tarballs and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the povr fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

---------------- povr-3.8.0-x.povr_1755021c.tar.gz  October 07, 2023
povr R9 v0.6.3.0

Fixed years standing bug in the newer POV-Ray parser used by the povr 
fork. A bug triggered when the total number of tokens parsed matched an 
internal default value at the point where Parser::Parse_RValue(...) was 
called. Aside from a few hard parser fails, it made for flaky parser and 
render behavior which would were rare but would ghost in and out of 
existence base on nearly any change in Scene Description Language (SDL) 
file.

Adding a blend_mode 4 option which applies the active gamma adjustment 
to the two weights rather than the color channel values. It allows more 
control over the graying which happens around the mid point of 
traditional interpolations.

The ancient, two index, two color format from v1.0 of POV-Ray is now a 
parse error. Too many potential, confusing pitfalls.

Added a set of bit wise operator functions in: 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() and 
f_64x_ui1_popcnt().

Added encoding into double space and decoding from double space 
functions: f_dec64x_ui1(), f_enc64x_ui1(), f_dec32x_ui2(), 
f_enc32x_ui2(), f_dec16x_ui4(), f_enc16x_ui4(), f_dec4x_ui16(), 
f_enc4x_ui16(), f_dec8x_ui8() and f_enc8x_ui8(). Think, tiny arrays in 
the space of a double which can be passed around in the parser and used 
with functions.

Added f_path() which supports two to 13 vertex specifications along with 
explicit point to point connections, sizing and tapering capability. 
Four basic vertex / point encoding methods. Aimed at isosurfaces and 
texturing objects. It acts somewhat like a limited segments, linear 
sphere_sweep.

Fleshed out it_ keyword support within warp turbulence blocks. Basically 
it_ prefixed keyword aliases for all traditional turbulence settings.

Added it_scale <float> support to the patterns 'agate' and 'wood'.

Added it_scale to the feature irid. The irid feature also now uses 
'it_amount' - replacing 'turbulence'. The internal inbuilt functions 
f_agate(), f_turbulence() and f_marble() were also updated.

The wood pattern itself was updated to remove the melding of x and y 
coordinates with returned DTurbulence() values as has been done since 
v1.0 of POV-Ray. Guess is the previous method was a way to fake 
different growth ring sizes but also requiring the user to carefully 
align the pattern to the surfaces. The povr fork has f_wood() and 
layered turbulences with the it_* keywords and as many 
warp{turbulence...} blocks as needed.

Added an 'it_amount' keyword to the it_ prefixed collection. Depending 
upon the context for usage, the argument might be a 3D vector (and in 
function be very like 'turbulence <3D vector>') or it might be a single 
float value and be used as a multiplier to a single returned 
Turbulence() float value at a point in 3D space. The wood pattern is the 
first pattern to make use of the keyword.

Added it_scale <float> support to warp { turbulence ... it_scale <float 
 > } and to the inbuilt function f_dturbulence(). In the warp{} case, 
the new keyword can usually replace the common 'turbulence scaling' 
sequence :

     scale 7
     warp { turbulence ... }
     scale 1/7

with

     warp { turbulence ... it_scale 1/7 }

Added a histogram.pov file to the DocAidScenes directory. One set up 
primarily to quickly render histograms of inbuilt patterns and functions 
to a pre-set value range.

[William F Pokorny] Updated povr tarballs for Unix/Linux. 96ed7ff3 [961 days 12 hours and 6 minutes ago]

Sat, 2 Sep 2023 14:31:45 GMT

Please see the attached tarballs and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the povr fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

---------------- povr-3.8.0-x.povr_96ed7ff3.tar.gz  September 02, 2023
povr R8 v0.6.2.0

Extending the _object, shape based pattern set. Renamed long existing 
'object' block / discrete (0|1 result) pattern 'bool_object'. Added two 
new shape based patterns called 'dens_object' and 'list_object'. The 
former returns a local surface based density value (as a proximity 
pattern stand-in). The latter is a 13 value block pattern. The patterns 
'bool_object', 'dens_object' and 'list_object' support up to 12 input 
objects. The object based pattern set in povr now numbers five, 
including 'hard_object' and 'soft_object' too. These last two still 
support only a single input object / shape.

Fixing asymmetrical scaling, sphere inside test. The inside test for 
the, Do_Ellipsoid, asymmetrical scaling case was broken in povr sometime 
during the vector initialization updates.

Updating isosurface. Changing some parse warning checks to hard errors. 
Removing the 'all_intersections' keyword. It has always been an alias 
for 'max_trace 10' and there was never parse time checking to be sure 
users didn't use both 'all_intersections' and 'max_trace'.

Changing the hard_object and soft_object patterns. Both now return -1..1 
or 'function_interval' value ranges. Modified the syntax too, bringing 
all the associated keywords inside the *_object{} block along with the 
referenced object.

Tuned the normal{} perturbation methods ripples and waves, along with 
the scalar value pattern implementations of ripples and waves, to better 
show an effect inside the 2^3 region about the origin. The ip_frequency 
setting is your friend when playing with these four ripples / waves 
implementation.

Inverted the cubic_wave, scalar value pattern modifier. In a closer look 
at results I realized I implemented it upside down.

Corrected long broken implementation of a sqr() function for both the 
parser and the function/vm environment used during parsing and rendering 
phases.

Releasing initial vim-editor, povr-specific, povr.vim and povini.vim 
syntax support files and associated povr.vim ftdetect file in a 
vim/dotVimDir included with the povr_docAndAid tarball. I've not yet 
looked at auto-indentation support. See vim directory README for more 
information.

Updates for a simple modeling set up with POV-Ray implemented using real 
time rendering (RTR) running within each frame of a long, traditional 
animation. An initial playpen implementation is included with the 
povr_docAndAid tarball.

Added the ability to specify a user povray.conf directory with the 
environment variable POVCON. Use to override any system (or null 
installed) configuration directories. The povr fork is trying to avoid 
user dot directory configurations as they are inflexible when running 
multiple versions of POV-Ray of the same generation.

Added a hard throw where users try to do an interior id = id copy. This 
operation is currently broken in more recent v3.8 code. Issue needs to 
be fixed eventually.

Removed code deleting textures and interiors from projected_through, 
light_source objects. Such objects not otherwise looked at for ray to 
object intersections unless the user explicitly adds them to the scene.

Initial attempt to break out the povr documentation and support (aid) 
files for POV-Ray (povr) as a secondary tarball. The documentation and 
support oriented tarball will have the prefix 
povr_docAndAid_<at_this_commit> aligning with each source code tarball. 
When unpacked it's a directory structure of plain text files.

Common, longstanding directive and keyword permissiveness with respect 
to leading hash '#' characters now hard parse errors where not correct. 
Fixing the syntax to the good, but the recently added word_is() and 
word_get() functionality more or less forces the long recommended forms.

Moved text, truetype font (ttf) based, object's quadratic solver to the 
CERN version used by many other shapes in the povr fork.

Corrected compound ttf character int8_t offsets. Added a little fudge 
while bounding character glyph components as some splines seemed to just 
scoot outside. Both fixes can result in slight differences in text / 
characters extents.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. 0883... [1110 days 20 hours and 41 minutes ago]

Thu, 6 Apr 2023 05:56:33 GMT

On 4/6/23 01:01, jr wrote:
> ok, thanks.  built it on the VM, gcc 10, all good.

Good to hear - thanks.

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. 0883... [1110 days 21 hours and 32 minutes ago]

Thu, 6 Apr 2023 05:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/4/23 09:00, jr wrote:
> > my gcc is "elderly", and compilation fails, alas. ...
> Yep. I think having a compiler not compliant to c++11 is the only way
> you can get that fail.

ok, thanks.  built it on the VM, gcc 10, all good.


regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. 0883... [1111 days 17 hours and 44 minutes ago]

Wed, 5 Apr 2023 08:53:05 GMT

On 4/4/23 09:00, jr wrote:
> my gcc is "elderly", and compilation fails, alas.  excerpt from build:

Yep. I think having a compiler not compliant to c++11 is the only way 
you can get that fail. I have in my head the configure program should 
kick out a warning if it cannot do certain c++11 things - those might 
not include the compile time asserts though.

Aside: All v3.8 releases, technically, require a c++11 compliant 
compiler - but there is fuzziness to be had for sure.

There is a configure script flag called: --enable-compile-warn which 
turns on a set of warnings (and turns off -w).

You can of course add more -wall -wextra come to mind as ones I run when 
just trying to clean up things a little - but I cannot find those notes 
at the moment...

Bill P.

[yesbird] Re: An updated povr tarball for Unix/Linux. 0883... [1112 days 10 hours and 3 minutes ago]

Tue, 4 Apr 2023 16:34:21 GMT

On 04/04/2023 18:54, jr wrote:
> btw, every reply you post here is also sent to my inbox.  Thunderbird "at work",
> huh ?!  ;-)
Sorry, it was default TB behaviour, I've turned it off.
--
YB

[jr] Re: An updated povr tarball for Unix/Linux. 0883... [1112 days 10 hours and 42 minutes ago]

Tue, 4 Apr 2023 15:55:00 GMT

hi,

yesbird <sya### [at] gmailcom> wrote:
> On 04/04/2023 16:00, jr wrote:
> > (btw, is there an option to turn on _all_ compiler warnings ?)
> I'm using following set:
> -pedantic -Wall -Wextra

thanks, yes those too.  there are (for gcc) various -Wxyz switches, I tend to
ask for shadow, format-security, strict-overflow, conversion, undef, and such.
(would have liked a single config option, rather than editing the build script
:-))

btw, every reply you post here is also sent to my inbox.  Thunderbird "at work",
huh ?!  ;-)

regards, jr.

[yesbird] Re: An updated povr tarball for Unix/Linux. 0883... [1112 days 12 hours and 29 minutes ago]

Tue, 4 Apr 2023 14:08:37 GMT

On 04/04/2023 16:00, jr wrote:
> (btw, is there an option to turn on _all_ compiler warnings ?)
I'm using following set:
-pedantic -Wall -Wextra
--
YB

[jr] Re: An updated povr tarball for Unix/Linux. 0883... [1112 days 13 hours and 22 minutes ago]

Tue, 4 Apr 2023 13:15:00 GMT

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

looks like the web ui didn't like the apostrophes supplied by compiler, trying
again:

> ...>   CXX      vm/fnintern.o
>   CXX      vm/fnpovfpu.o

vm/fnintern.cpp: In function 'double pov::fnEnc2x_f32(double, double)':
vm/fnintern.cpp:153:38:error: expected ',' before ')' token

>      static_assert(sizeof(float)  == 4);    // These I think redundant for c++11


regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. 0883... [1112 days 13 hours and 32 minutes ago]

Tue, 4 Apr 2023 13:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> povr R7 v0.6.1.0

my gcc is "elderly", and compilation fails, alas.  excerpt from build:

Script started on Tue 04 Apr 2023 13:46:03 BST
  ...
===============================================================================
POV-Ray (povr) 3.8.0-x.povr_0883e2b6 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
    -ffast-math -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
    -lpthread

The POV-Ray (povr) components will be installed in the following directories:
  Program (executable):       /home/jr/POVr/bin
  System configuration files: /home/jr/POVr/etc/povray/3.8
  User configuration files:   /home/jr/.povray/3.8 (povr ignoring)
  Standard include files:     /home/jr/POVr/share/povray-3.8/include
  Standard INI files:         /home/jr/POVr/share/povray-3.8/ini
  Standard demo scene files:  /home/jr/POVr/share/povray-3.8/scenes
  Documentation (text, HTML): /home/jr/POVr/share/doc/povray-3.8
  Unix man page:              /home/jr/POVr/man
===============================================================================
  ...

See the file INSTALL.txt for more build options and information.
make  all-recursive
make[1]: Entering directory '/tmp/POV/povray-3.8.0-x.povr_0883e2b6'
Making all in source
make[2]: Entering directory '/tmp/POV/povray-3.8.0-x.povr_0883e2b6/source'
  CXX      base/mathutil.o
  ...
  CXX      povms/povmsutil.o
  CXX      vm/fnintern.o
  CXX      vm/fnpovfpu.o
vm/fnintern.cpp: In function ‘double pov::fnEnc2x_f32(double, double)’:
vm/fnintern.cpp:153:38:error: expected ‘,’ before ‘)’ token
     static_assert(sizeof(float)  == 4);    // These I think redundant for c++11
  ...
Makefile:1311: recipe for target 'vm/fnintern.o' failed
make[2]: *** [vm/fnintern.o] Error 1
  ...

(btw, is there an option to turn on _all_ compiler warnings ?)


regards, jr.

[ingo] Re: An updated povr tarball for Unix/Linux. 0883... [1113 days 20 hours and 57 minutes ago]

Mon, 3 Apr 2023 05:40:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarball [...]

Thank you.


ingo

[William F Pokorny] An updated povr tarball for Unix/Linux. 0883e2b6 [1114 days 9 hours and 7 minutes ago]

Sun, 2 Apr 2023 17:30:42 GMT

Please see the attached tarball and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the povr fork is not POV-Ray. As time passes, it's less 
likely existing POV-Ray scenes will work without modification.

Bill P.

---

--------------------- povr-3.8.0-x.povr_0883e2b6.tar.gz  April 02, 2023
povr R7 v0.6.1.0

Found the povr fork picked up Christoph's late 2018 and early 2019 
text{} block cmap{} keyword code changes intended to enable support of 
more true type font (.ttf) files. The functionality looks useful in 
testing and - though not planned - the povr fork will keep the work. See 
the keyword documentation for more information.

Removed the 'hf_gray_16' and 'hf_grey_16' keywords. These have not 
functioned since v3.6 and they only existed to generate a warning 
message that they no longer worked.  All v3.7 onward gray file output 
control is accomplished with ini keywords or command line flags.

Updated RTR_HACK configuration so it can disabled by setting RTR_HACK to 
0 at build / compilation. Disabling previously required a header file 
edit to comment or remove the definition.

Adding the SDL functions word_is() and word_get(). These access and make 
use of 18 internal arrays of token information relative to the active 
version of POV-Ray(povr). The 18 arrays break down into three sets. 
Namely. Previous tokens (back to through v3.6) which are out (o prefix); 
Tokens included in the current code (i prefix); Lastly, tokens which are 
new (n prefix) compared to the prior major release (v3.8 beta 2). See 
documentation for more detail on use.

In debug compiles the internal function f_boom() now does a hard assert 
rather than a handled throw to enable the creation of core dump files.

Changes to cone / cylinder base==apex error handling. Formerly a throw 
was triggered - which did not generate a core dump file. Updates made so 
in non-debug compiles the parser generates PossibleErrors and continues. 
In debug compiles a hard assert condition is raised. This stops parsing 
and enables the generation a core dump file.

Added configuration option POV_File_Text_INC_DEBUG. Set to 1 to get 
include debug output as files are read. Default is 0.

Restoring v3.7 ifdef, ifndef and defined() ID only behavior.

The ripples and waves patterns largely re-written as they had a 
significant number of issues. Not the least of which was depending upon 
a global_settings{} number_of_waves keyword initialized in each thread 
and not identically.  See documentation and related newsgroup posts. The 
frequency and phase collisions with internal pattern values should be 
considered a part of the ripples and waves re-work and those issues were 
previously fixed with ip_frequency and ip_phase.

Changes to make the height_field image handling more consistent. Indexed 
images which have long produced a very weak height (for historical 
reasons) are now illegal. Color image handling for <=8 and >8 bit depth 
images is now all using the inbuilt, standard color to grey conversion. 
In other words, the special red weighted, red+green gray conversion for 
<=8 bit depths is gone.

Fixed color image_map out of bounds transparency so it no longer sets 
the r,g and b channels to 1.0. Something which led to inconsistent 
channel results depending on how information was accessed both within 
the program and by users.

Allowing average keyword within map declarations alongside blend_map and 
blend_gamma so predefined maps can be declared ahead of time for later 
average pattern use. Without this change it was impossible to create a 
map id for use with average. In other words, previously, everything had 
to be defined within the entity using the average pattern.

Added a set of complex functions defined and documented in the include 
file cfunctions.inc. The current list mostly follows that in c++11 on 
and currently includes: cf_abs, cf_acos, cf_acosh, cf_add, cf_asin, 
cf_asinh, cf_atan, cf_atanh, cf_cmplx, cf_conj, cf_cos, cf_cosh, cf_div, 
cf_exp, cf_imag, cf_inv, cf_ln, cf_log, cf_mul, cf_neg, cf_norm, 
cf_phase, cf_polar, cf_pow, cf_proj, cf_real, cf_sin, cf_sinh, cf_sqr, 
cf_sqrt, cf_sub, cf_tan and cf_tanh

Added a new inbuilt scene and function vm keyword in log2 which wraps 
the c++ std::log2. Note c++ log and log10 names are ln and log, 
respectively, with POV-Ray. A reason to make log2 inbuilt is 
performance. Along with floor and ceil, log2 can be reliably used to 
detect numerical values having a power of two encoding.

[jr] Re: An updated povr tarball for Unix/Linux. 7c1a... [1142 days 20 hours and 12 minutes ago]

Sun, 5 Mar 2023 06:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please see the attached tarball and previous announcements in this fora
> and INSTALL.txt for suggestions on compiling and running via wrapper script.
>
> A reminder the povr fork is not POV-Ray. As time pass it's less likely
> existing POV-Ray scenes will work without modification.

great, cheers.  "todo", in the coming days.


regards, jr.

[William F Pokorny] An updated povr tarball for Unix/Linux. 7c1adb79 [1142 days 23 hours and 33 minutes ago]

Sun, 5 Mar 2023 03:04:43 GMT

Please see the attached tarball and previous announcements in this fora 
and INSTALL.txt for suggestions on compiling and running via wrapper script.

A reminder the povr fork is not POV-Ray. As time pass it's less likely 
existing POV-Ray scenes will work without modification.

Bill P.

---

--------------------- povr-3.8.0-x.povr_7c1adb79.tar.gz  Mar 04, 2023

A povr specific fix for an 08 Feb 2023 post by Chris R to beta-test with 
the title: Spline causing 3.8 beta 2 to crash.

Adding new includes in version.inc and forkversion.inc. These includes 
make use of fork_str() and fork_val() parser constants - when available 
- to support running modified versions of POV-Ray alongside nominally 
POV-Ray release aligned compiles. See the include files for more 
information and example usage. In other words, these additions enable 
users to set up conditional behavior with respect to particular forks in 
their scene description language (SDL) files.

Adding reflection block keyword inv_pnormal_cure to expose and 
explicitly make available fixes / modifications to reflected rays any 
time a normal{} block is used in a texture / material. The current 
available options are 0-5,11. See postings to v4.0 discussion forum for 
more information. The default was left at (1) which was the previously 
'secrete to users' three-way set of internal fixes. Yes, the code being 
exposed here in the SDL has long been twiddling with reflected rays and 
so reflection results. The effects are mostly muted where the bump_sizes 
are small and the reflections not near tangent to the surface.

Adding reflection block specific intensity_max. Applies specifically to 
reflection as handled with 1-n layered textures and unavoidably overlaps 
somewhat with the finish blocks overall intensity_max if it too is active.

Hacked a patch for openexr read with large floats. Problem values being 
those larger than about 2^16. Causing unavoidable speckling / blotchy 
patches both light and dark per color channel - depending on features 
used. What was seen for issues depends some on -ffast-math equivalent 
compiler settings. Added code a more controls around EXR_PRESCAN_PATCH 
(defaulted on) and POV_PIGMENT_DEBUG (defaulted off) settings. The 
latter becomes active with POV_DEBUG compiles and it looks for similar 
+-inf channel issues coming from anywhere - necessary because some of 
our colour (ie colour.h) code attempts to fix up bad color channel 
values and tends to hide issues, like the openexr one here, in doing so. 
The hack patch should be removed for code correctly handling exr files 
with larger full float values on move to exr 3.0.

Created an official normal block pattern called micro from the bevy 9 
test bed and corrected a bug not initially picked up in the original 
bevy 9 implementation where the result in x somewhat mangled.  It's 
depends on Anti-Aliasing (AA) for overall effect. Use: normal { micro 
0.01 }.

Added a fix to code setting up for the use of Intersect_BBox to avoid 
floating point exceptions causing unstable downstream numerical issues. 
Maintaining the ability to use --ffast-math with this fix a win for 
performance, but the fix is itself somewhat costly - especially given 
the exposure for most users is not that common. Perhaps better can be 
worked out later - understand the gains and impacts of Intersect_BBox first.

This version of the source code is configured with the useless zeroing 
of vector components due our vector.h template code turned off. Much 
work done to find needed initializations to zero (or other values) being 
hidden / obfuscated by the previous behavior. NOTE! Odds are good I 
missed something somewhere. Expecting this true, added a new 
configuration option in --enable-vector-zeroing which restores the 
previous zeroing behavior on vector construction / allocation. Aside: 
The broader adoption of vector.h in v3.8 is 2-3% of that 16% v3.7 / v3.8 
slowdown that came with that commit moving more strongly toward C++ 
methods. See: github GH363 / #363.

Fixing background/skysphere radiosity bug which had been, unfortunately, 
long mitigated by the extra initializations of vector components to zero 
in vector.h.

Minor cleanup in internal functions and vm. A few run time asserts made 
compile time static. Added static asserts to prevent the VM's integer 
opcodes from being compiled should someone turn on that compile option - 
the implementation is not complete with respect to POV-Ray in total.

Attempted to restore a little run time error reporting in the VM. The 
error reporting has long been disabled unsure when this happened 
(v3.7/v3.8?).

Reworked the sphere.cpp code in moving away from DEPTH_TOLERANCE, 
EPSILON to gkMinIsectDepthReturned or gkDBL_epsilon. Expected accuracy 
for the shape should be better by about two orders of magnitude. We have 
still the issue spheres, like sphere_sweeps and a few others eliminates 
transforms where the sphere's internal representation can be changed to 
represent the same thing.  This approach is likely faster, but it hurts 
numerically.

In testing POVMS with an active POVMS POVMS_NO_ORDERED_STREAM_DATA to 
see if performance faster as expected, I found a bug where I'd not 
previously gotten the float to double right. The option surprisingly was 
not faster though certainly looks like it should be. Likely why it's set 
as is and the bug fix likely useless practically.

Adding explicit internal initializations of INormal and PNormal where 
missing in preparation of trying to eliminate the mostly useless 
initializations to zero in vector.h.

Additional code clean up for compiler warnings. Changing DBL to double, 
FLT to float. Old generic EPSILON to gkMinIsectDepthReturned or 
gkDBL_epsilon as appropriate. No intended change in behavior, but at the 
very edges internally there could be as related to EPSILON.

While cleaning code corrected (at least better) old off center cubic DF3 
interpolation (12) at the edges. Wrap was wrong - is wrong in the v3.8 
release code give POV-Ray proper never adopted the off-shift fixes many 
years ago.

Turning off additional asserts for normal compiles. Many non debug 
parser ones especially were set soft rather than disable. The povr 
branch approach is normal compiles without asserts and a possible second 
compile with asserts and much more run time checking when issues pop up. 
Removing the asserts speeds up the parser so it is faster on average 
than the v3.8 release one.

[jr] Re: An updated povr tarball for Unix/Linux. 6e4e... [1628 days 15 hours and 32 minutes ago]

Thu, 4 Nov 2021 11:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> See the attached tarball.
>
> A work in progress. As time passes the povr branch is drifting farther
> from POV-Ray v3.8 proper. I expect a majority of old scenes now would
> need some changes to work.

thanks.  built it, tested (so far) with two rtr scenes and the Filed()[*] demos,
all seems fine, feels .. snappy.  (ran into needing braces for reflection :-))

[*] now think that 'fild__rdFile()' is "the culprit".


> And jr! I did not get to the x11 -into / -wid work again. However, some
> of the recent rtr changes are related. My thinking now is to hook that
> feature into the real time rendering stuff as completely new x11 code
> rather than hack the existing code as I attempted last time. This will
> also let us bypass the internal messaging (and the memory bubble) for
> RTR display - and RTR is where I'd like to use the feature for cheap
> modeling ;-).

any excuse, as far as I'm concerned :-)  looking forward to that option.


regards, jr.

[William F Pokorny] An updated povr tarball for Unix/Linux. 6e4ed6c2 [1637 days 11 hours and 25 minutes ago]

Tue, 26 Oct 2021 15:11:56 GMT

See the attached tarball.

A work in progress. As time passes the povr branch is drifting farther
from POV-Ray v3.8 proper. I expect a majority of old scenes now would
need some changes to work.

And jr! I did not get to the x11 -into / -wid work again. However, some
of the recent rtr changes are related. My thinking now is to hook that
feature into the real time rendering stuff as completely new x11 code
rather than hack the existing code as I attempted last time. This will
also let us bypass the internal messaging (and the memory bubble) for
RTR display - and RTR is where I'd like to use the feature for cheap
modeling ;-).

The new amplify and intensity_max keywords work where they work, but not
everything is done - media being the pink elephant. Mostly you can just
not use them, but the old, long deprecated, shorthand of say 'reflection
1' will no longer works. It must be the newer reflection { 1 } style.

The emission keyword on sky_spheres is now amplify. Oh, the global
settings ambient_light keyword is gone. In povr the direction is toward
adding 'amplify' in each block over the one global setting. The idea
with amplify is to set up global color vector variables - and so better
enable in SDL what many do already in scenes today for development and
debugging purposes.

#declare Amplify_ambient_emission = rgb <1,1,1>;
#declare Amplify_reflection = rgb <1,1,1>;

... finish {amplify Amplify_ambient_emission ...}

Oh, I was asked about the new getenv() feature and why it was needed for
environmental HDRIs. It's not. It is a general feature to pull
environment variable settings into SDL as strings (probably, best to
stick with ascii). It just happened in my earlier post, that I used an
environment variable called HDRI and so the code to reference the
environment HDRI image file I was using ended up as: getenv("HDRI").

Still not a lot of shipped documentation though there is a povr specific
revision file in the <install_dir>/doc/povrTextDocumentation directory.

For more detail on compiling etc. see previous post:

http://news.povray.org/povray.binaries.programming/thread/%3C60b2aaf6%40news.povray.org%3E/

Web message: <60b2aaf6@news.povray.org>

Or <install>/INSTALL.txt

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. 1984... [1771 days 6 hours and 42 minutes ago]

Mon, 14 Jun 2021 19:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Interesting. Thanks. I've captured your patch and this post to a sub
> directory of my jr_causing_trouble directory... :-)

</grin>  perhaps amend directory name to and_posting_buggy_code!  found one (the
first?), the "if .. else if' in 'mkFname' need ">=" operators (or literals + 1,
or 'last - 1').

regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. 1984... [1771 days 16 hours and 2 minutes ago]

Mon, 14 Jun 2021 10:35:17 GMT

On 6/12/21 7:12 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 6/9/21 11:46 AM, jr wrote:
>>> ...
...
> 
> had a look at the xwd-1.0.6 source and modified (quick hack) the main function
> to create N files from the given window.  no syncing though, adding another
> option to specify a delay after each file might help a little.  patch attached
> just in case, but anyway, it would be a "crutch" at best.
> 
> tested a couple of times with small number frames, running a 'povr' with the
> command-line given in 'rtr_kla.pov'.  then the modified 'xwd' ('-nfrm' + '-out'
> required):
> 
>    $ ./xwd -nfrm 10 -out /tmp/foo -name "POV-Ray (povr) 3.8 povr X11 "
> 
> creates '/tmp/foo_00.xwd' etc.  I used 'xv' for visual check:
> 
>    $ xv /tmp/foo*.xwd
> 
> (curiously, could only identify 'povr' window name + class, but no id shown)
> 
...

Interesting. Thanks. I've captured your patch and this post to a sub 
directory of my jr_causing_trouble directory... :-)

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. 1984... [1773 days 3 hours and 22 minutes ago]

Sat, 12 Jun 2021 23:15:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/9/21 11:46 AM, jr wrote:
> > ...
> > may be 'xwd' (and 'xwud') can help?  not sure how you'd automate the syncing
> > though.
>
> Yeah, maybe. A long while back now, I did play a little with xwd - stand
> alone just snapping a paused preview window. Hit some issue that looked
> to be related to quantization or a shift of color values. I could not
> quickly sort it and I dropped the work - work that's been on the floor a
> long while now. In truth it's 'play' down my list at the moment -
> though(1) ;-).
>
> I 'believe' in rtr much of the work needed to create an output image is
> still done for each frame, perhaps I just need to figure out how to
> pause and trigger a write to unique output files. ...

had a look at the xwd-1.0.6 source and modified (quick hack) the main function
to create N files from the given window.  no syncing though, adding another
option to specify a delay after each file might help a little.  patch attached
just in case, but anyway, it would be a "crutch" at best.

tested a couple of times with small number frames, running a 'povr' with the
command-line given in 'rtr_kla.pov'.  then the modified 'xwd' ('-nfrm' + '-out'
required):

  $ ./xwd -nfrm 10 -out /tmp/foo -name "POV-Ray (povr) 3.8 povr X11 "

creates '/tmp/foo_00.xwd' etc.  I used 'xv' for visual check:

  $ xv /tmp/foo*.xwd

(curiously, could only identify 'povr' window name + class, but no id shown)

regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. 1984... [1773 days 10 hours and 49 minutes ago]

Sat, 12 Jun 2021 15:48:11 GMT

On 6/9/21 11:46 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> Yep, rtr is cool and I hope use it (or similar) for more than demos -
>> eventually.
>> ...
>> Just need to work out how to capture each rendered frame to an image file...
> 
> may be 'xwd' (and 'xwud') can help?  not sure how you'd automate the syncing
> though.
> 

Yeah, maybe. A long while back now, I did play a little with xwd - stand 
alone just snapping a paused preview window. Hit some issue that looked 
to be related to quantization or a shift of color values. I could not 
quickly sort it and I dropped the work - work that's been on the floor a 
long while now. In truth it's 'play' down my list at the moment - 
though(1) ;-).

I 'believe' in rtr much of the work needed to create an output image is 
still done for each frame, perhaps I just need to figure out how to 
pause and trigger a write to unique output files. Oh, and some way to 
run through all the cameras only once I guess.

Bill P.

(1) - Banging around my head of late is the idea that with functions we 
can perhaps create a collection of inbuilts that query generic 
environmental information and return a 'change-this' result(1a) which 
could be used during the render of each frame. With >= v3.8 we have 
stuff like user_defined cameras, pigments and densities(media)... We 
have longer had stuff like isosurfaces, parametrics. Supposing such a 
collection of inbuilt functions, might we be able to change quite a lot 
more stuff frame to frame in rtr? Arbitrarily fly about a scene with a 
couple user defined camera definitions which are no longer static?

(1a) - Expect too might need f_delay, f_pause_resume like inbuilt 
functions rather than just functions that might query the state of 
values in some file say. Guess f_delay might be useful all by itself.

[jr] Re: An updated povr tarball for Unix/Linux. 1984... [1776 days 10 hours and 47 minutes ago]

Wed, 9 Jun 2021 15:50:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Yep, rtr is cool and I hope use it (or similar) for more than demos -
> eventually.
> ...
> Just need to work out how to capture each rendered frame to an image file...

may be 'xwd' (and 'xwud') can help?  not sure how you'd automate the syncing
though.


regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. 1984... [1777 days and 41 minutes ago]

Wed, 9 Jun 2021 01:56:00 GMT

On 6/1/21 9:50 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> An updated tarball of my povr branch. A little rushed, but want to post
>> a new one ahead of being busy with real life for a bit.
>> ...
> 
> Thank you.
> 
> Have you considered using Travis to do automatic testing of povr after each
> commit to Github ?
> 
...

Tor Olav & Christoph, I'm aware of those offerings, if not precisely how 
to use them. There is a place for such release build testing I'd say, 
though I'm not sure what form(s) it'll all take for me in the future.

Bill P.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. 1984... [1777 days and 42 minutes ago]

Wed, 9 Jun 2021 01:55:14 GMT

On 5/30/21 6:58 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> An updated tarball of my povr branch. A little rushed, but want to post
>> a new one ahead of being busy with real life for a bit.
>> ...
>> version is small (5-6MB). The compiled in place ones sits at about 50MB
>> post build - mostly due all the object files.
> 
> compiles/builds cleanly, installed size (including source tree) ~14M.  thank
> you.  (need to find out about 'rtr'!.  v impressive)
> 

Thanks for giving it go!

Yep, rtr is cool and I hope use it (or similar) for more than demos - 
eventually.

Aside: Credit for the real time ray tracing feature goes back mostly to 
Chris and Thorsten - as far as I know. My work amounts to getting it to 
work with unix/linux builds - with Jerome providing helpful background 
information.

The test scene set up is mine and it explores another way to parse a 
multi frame animations once. Just need to work out how to capture each 
rendered frame to an image file...

Aside: There is too that crazy-neat, more or less works already, idea of 
Kenneth's for using rtr to build up better radiosity samples files. Need 
to get back to playing with that and the related ideas of otherwise 
implemented/faked radiosity file creation...

Bill P.

[clipka] Re: An updated povr tarball for Unix/Linux. 1984... [1782 days 21 hours and 5 minutes ago]

Thu, 3 Jun 2021 05:32:06 GMT

Am 02.06.2021 um 08:12 schrieb clipka:
> If you're hosting on GitHub, I'd strongly recommend instead looking to 
> GitHub Workflows, aka GitHub Actions. It just so happens that I 
> discovered and toyed with it just yesterday.
...
> Caveat:
> 
> - For organizations, the free plan includes only 2000 min/month of time 
> to run stuff. (AFAIU, there is no such limit for repos owned by 
> individual users, at least for private repos.)

Correction:

There is a limit of 2000 min/month for private repos, no matter whether 
you are an org or individual user.

There is no such limit for public repos, you can run as much stuff as 
you like.

[Tor Olav Kristensen] Re: An updated povr tarball for Unix/Linux. 1984... [1783 days 7 hours and 57 minutes ago]

Wed, 2 Jun 2021 18:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 02.06.2021 um 03:50 schrieb Tor Olav Kristensen:
>
> > Have you considered using Travis to do automatic testing of povr after each
> > commit to Github ?
> >
> > https://docs.travis-ci.com/user/languages/c/#ci-environment-for-c-projects
> >
> > Travis is, AFAIK, free to use for open source projects.
>
> It is. I'm not sure I'd recommend it though.
>
> Yes, it is a German company so that's a pro ;). But there are other
> alternatives:
>...

Thank you for reviewing the options.

My needs were quite modest compared to what may be needed for POV-Ray.
But it was very interesting to look into such tools and try one of them.

I'm sure that we can implement some smart automated testing with one of the
alternatives that you mentioned.

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

[clipka] Re: An updated povr tarball for Unix/Linux. 1984... [1783 days 20 hours and 24 minutes ago]

Wed, 2 Jun 2021 06:12:52 GMT

Am 02.06.2021 um 03:50 schrieb Tor Olav Kristensen:

> Have you considered using Travis to do automatic testing of povr after each
> commit to Github ?
> 
> https://docs.travis-ci.com/user/languages/c/#ci-environment-for-c-projects
> 
> Travis is, AFAIK, free to use for open source projects.

It is. I'm not sure I'd recommend it though.

Yes, it is a German company so that's a pro ;). But there are other 
alternatives:

- If you want something braindead simple, go to Semaphore.

- If you want something very flexible, two days ago I would have 
recommended AppVeyor, because it is a good deal more powerful (or was, 
last time I checked) than Travis CI, and also supports Windows builds. 
Well, I just double-checked and found that Travis CI does that, too, by 
now. Still, I think AppVeyor has a slightly larger portfolio of OS versions.


   *** BUT ***

If you're hosting on GitHub, I'd strongly recommend instead looking to 
GitHub Workflows, aka GitHub Actions. It just so happens that I 
discovered and toyed with it just yesterday.

Pros:

- Pretty much identical choice of platforms as the others.

- Easy to set up if you're after something simple, thanks to various 
pre-made templates.

- Crazy amount of flexibility if you so desire, regardin the "build 
matrix", i.e. which combination of platforms, compilers, build scripts 
and whatnot you're using, which combinations NOT to use, on what 
branches and under what circumstances to use them, which steps to skip 
under which conditions, which jobs have to complete before starting 
others, and other such bells & whistles - all while still being 
reasonably sane to wrap your brain around.

- Crazy amount of flexibility what steps your job is comprised of (no 
hard-wired "pre-buld / build / post-build / deploy" sequence).

- Avoids signing up yet another account on yet another service.

   *** AND ***

in my opinion the most important advantage of all:

- While you're at it, you can use the exact same mechanism to set up 
build tests (or other jobs) that you can trigger MANUALLY.

For example, you can set up just a simple automated test to run on each 
check-in, and run exhaustive platform compatibility tests only on demand.

(Or, you can set up automated actions in some branches, but keep the 
opportunity to manually trigger them on others.)


Caveat:

- For organizations, the free plan includes only 2000 min/month of time 
to run stuff. (AFAIU, there is no such limit for repos owned by 
individual users, at least for private repos.)

[Tor Olav Kristensen] Re: An updated povr tarball for Unix/Linux. 1984... [1784 days and 42 minutes ago]

Wed, 2 Jun 2021 01:55:00 GMT

William F Pokorny <ano### [at] anonymousorg> wrote:
> An updated tarball of my povr branch. A little rushed, but want to post
> a new one ahead of being busy with real life for a bit.
>...

Thank you.

Have you considered using Travis to do automatic testing of povr after each
commit to Github ?

https://docs.travis-ci.com/user/languages/c/#ci-environment-for-c-projects

Travis is, AFAIK, free to use for open source projects.

Perhaps Travis also can be used to test many of the macros in the include files.
If so it may be that we can move much of the SDL code for macro testing out of
the include files and into separate test files.

For my scikit-vectors library I have written test code for testing the library.
They are here:
https://github.com/t-o-k/scikit-vectors/tree/master/skvectors/tests

Travis runs these with the Python versions that I've chosen every time I make a
commit to Github and e-mails me if something fails.

The results can also be seen here:
https://travis-ci.com/github/t-o-k/scikit-vectors

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

[jr] Re: An updated povr tarball for Unix/Linux. 1984... [1786 days 15 hours and 37 minutes ago]

Sun, 30 May 2021 11:00:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> An updated tarball of my povr branch. A little rushed, but want to post
> a new one ahead of being busy with real life for a bit.
> ...
> version is small (5-6MB). The compiled in place ones sits at about 50MB
> post build - mostly due all the object files.

compiles/builds cleanly, installed size (including source tree) ~14M.  thank
you.  (need to find out about 'rtr'!.  v impressive)

regards, jr.

[clipka] Re: An updated povr tarball for Unix/Linux. b0bc... [1787 days 1 hour and 29 minutes ago]

Sun, 30 May 2021 01:08:19 GMT

Am 26.04.2021 um 13:25 schrieb William F Pokorny:

> The srgb keywords now permit inputs ONLY in the 0 to 1 range for which 
> the srgb color space is defined. Previously values outside the range 
> generated linear values but ones not making any particular sense.

Technically, contrary to Ive's claim (who is usually right in such 
things), the sRGB color space _is_ well-defined(*) for values outside 
the 0..1 range, both positive and negative.

The official sRGB specification (v1.10) refers to limiting the color 
values to the 0..1 regime as "typical", and _in such cases_ mandates 
that simple clipping is to be used for this purpose, but there is no 
provision mandating gamut limiting _per se_, and there is no fundamental 
mathematical problem with the functions outside the range.

(* Note that I'm not saying well-suited. That would be an entirely 
different discussion.)

[William F Pokorny] An updated povr tarball for Unix/Linux. 1984d6ea [1787 days 5 hours and 39 minutes ago]

Sat, 29 May 2021 20:58:30 GMT

An updated tarball of my povr branch. A little rushed, but want to post 
a new one ahead of being busy with real life for a bit.

Copy to a directory where you want to try and compile. For me it was 
/tmp/testTar.

mkdir /tmp/testTar
cd /tmp/testTar
     <download povray-3.8.0-x.povr_1984d6ea.tar.gz>
tar -zxvpf povray-3.8.0-x.povr_1984d6ea.tar.gz
cd povray-3.8.0-x.povr_1984d6ea

./configure -q COMPILED_BY="WFP" \
CXXFLAGS="-std=c++11 -O3 -ffast-math -march=native" \
LDFLAGS="-s" --prefix=/dev/null

make -j4

make check

Copied 'povr' script in root build directory to an executable location 
in my PATH environment variable ($HOME/bin for me). An edit of this 
'povr' wrapper script to point to where I did my test compile:

COMPILEDIR=/tmp/testTar/povray-3.8.0-x.povr_1984d6ea

Then:

cd /tmp/testTar/povray-3.8.0-x.povr_1984d6ea/scenes

povr --version
    or via full path
$HOME/bin/povr --version

Then:

povr biscuit.pov +w800 +h600 -fn +p

povr rtr_kla.pov -cc -fn +a0.3 +am2 +r2 +w80 +h200 +rtr +kla
    (q in window to stop or cntl-c)

cd fog

povr fog.pov +w800 +h600 -fn +p

...

You can also set the ./configure --prefix to a real install location. 
The povr wrapper script can point to that instead and the 'installed' 
version is small (5-6MB). The compiled in place ones sits at about 50MB 
post build - mostly due all the object files.

See the files INSTALL.txt and README.txt for more information. 
Debugging, options for faster executables and so on.

Oh, documentation is light, but there is stuff in:
./doc/povrTextDocumentation

Bill P.

[William F Pokorny] An updated povr tarball for Unix/Linux. b0bcf6c0 [1820 days 15 hours and 12 minutes ago]

Mon, 26 Apr 2021 11:25:32 GMT

The autotools build system has been significantly reworked and the povr 
tarballs are now created with 'make distcheck'. See the files 
INSTALL.txt and README.txt for more detail. The autotools quiet options 
are now available and sometimes defaulted. Use ./configure -q when 
configuring for the full quiet mode for configuration and build.

The default display is now X11 with a Simple Directmedia Layer an option 
by default, if an appropriate development library is found.

The srgb keywords now permit inputs ONLY in the 0 to 1 range for which 
the srgb color space is defined. Previously values outside the range 
generated linear values but ones not making any particular sense.

Fixes for broken dictionary copies. Suspect copies never worked - 
reliably - though perhaps sometimes appeared to work depending upon use.

Additional base v3.8 fixes not github issues documented in the news 
group: http://news.povray.org/povray.beta-test/

Of note .grey,.gray is broken in the v3.8 master branch and fixed in the 
povr branch. While fixing added a configure GREYREC option with several 
variations (111, 240, 601 709 and 2020) and the default was changed to 
the more reasonable sRGB assumed_gamma 1.0 BT709. Note 111 is the older 
color to gray conversion.

Additional changes have been made to the collection of inbuilt 
functions. See include/functions.inc for details. The majority of old 
functions for particular shapes no longer exist. This work is 
stabilizing, but it is not yet complete.

Of note are new functions support 21 bit and 32 bit encoding and 
decoding into and from a double. A few of the inbuilt functions make use 
of the capability to run once an internal vturbulence, say, and pass 
back 2d or 3d vectors.  Plus, f_dec_nbit3c and f_enc_nbit3c which permit 
the encoding of up to 51 bit (normally 48) bit depth values/grays in 
three color channels.

A significant number of self tests added to the core include files - 
especially functions.inc.

Fixed problems with method 3 antialiasing. Extended the older method 1 
and 2 modes so jitter is off by default. Jitter values, when on, can now 
be much larger than 1.0 - which is necessary to avoid grid artifacts and 
poor AA at larger recursion depths. Jitter also made truly random where 
it long has not been despite POV-Ray documentation. The aa values of 0.0 
now support fast paths - and with the big jitter values enable 
interesting effects.  See news groups for more detail pending better 
documentation.

A number of fixes and improvements to parsing and parse messages.

Patterns using internal turbulence moved to new it_ prefixed keywords. 
Where the pattern had an internal frequency or other keywords colliding 
with more general modifier keywords, new ip_ prefixed keywords were 
introduced. The ip_ prefix stands for internal pattern. The it_ prefix 
stands for internal turbulence.

The prefixed keywords added are : ip_frequency, ip_phase, ip_scale, 
it_depth, it_frequency, it_lambda, it_magnitude, it_octaves, it_omega, 
it_translate and it_scale. These keywords make clear intent and 
operation. These changes also fix issues long in POV-Ray where certain 
warps and operations like the frequency keyword were getting used twice 
for a completely incorrect results in some cases (ripples, waves) and in 
otherwise confusing and difficult to control results.

Isosurface evaluate feature pulled and a new report on/off keyword added 
so gradient warnings can be turned off or on by particular isosurface. 
Where functions filtered by other functions there is always a 
discontinuity on the function switch. Where these are not near the 
surface they don't matter to the result making the max gradient report 
noise.

Remaining default color maps removed for all no discrete patterns (for 
all continuous patterns)

The aoi pattern was changed to support the full -1 to +1 range as this 
today happens with perturbed normal patters where the original normal 
inverts with respect to the camera ray and the original surface.

The normal block quilted pattern was fixed for issues dating to its 
creation and extended lo, hi options added. The value based quilted 
pattern was dropped as it was anything, but quilted. New tiled and 
grooved normal block only patterns were added, the latter having too a 
flip keyword.

A new seedfi - "seed function interval" scalar value pattern was added 
with a -1 to 1 range which can be mangled by wave and pattern modifiers 
to create many additional patterns.

Improvements to mesh parsing code especially with respect to some 
particularly misleading error messages.

More generally where flags and keywords not supported in v3.7/v3.8 or 
the povr branch, they've been removed in a way which will cause errors 
during initialization phases and parsing.

Bill P.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2062 days 15 hours and 7 minutes ago]

Thu, 27 Aug 2020 11:30:01 GMT

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

> An investigation not as pattern but as warp could be interesting.

Aha, yes - that's a better way of thinking about it.

> The early part to answer is: what happen outside the circle.
> One answer can be: nothing, outside the circle, there is no transformation.

That would be my initial, naive impression.  Something like "once".

> Or something different, as suggested in the pdf for poincarrÃ© disk.

I'm sure that there exist a number of different options, and of course we will
probably find out what they are once someone picks up this sort of thing to
begin experimenting with and proceeds to discover what other ways there are or
follows a path of reasoning to suggest a new option.

Geometric inversion?

> It is "of course" to be mainly used with the image pattern, so it is
> better from the very start that the reference plane be the same (to
> avoid a systematic rotate), and the third coordinates is to be dropped.

Oh, please, no.   One of my main dislikes of things like prism {} is that the
coordinates are supplied in <x, z> format.  So then rather than simply passing
[multipurpose] vectors to the object definition, where the y-component gets
_ignored_, I have to write a whole new section of code to convert everything
into a special single-purpose format.   :(

> So far the "perfect" illustration could be some pedestal table with such
> topping, and some chess set on it...
> With an outer ring, which implies some layered textures too.

Likely.  But I also envisioned seeing how all of the various tilings can be
manipulated.   :)

> About bezier bicubic patches, I do not so far understand what is the
> final purpose of the request. Does it sound like gluing the mesh camera
> to a bezier bicubic patch ? (mesh camera or user-function defined camera).
> As a raytracing aims at generating pictures, what is a finish map in
> that context ?

The idea would be to define 4 corners of the bezier patch in terms of - not
<x,y,z> - but <r, g, b> and then rather than doing a straight bilinear
interpolation of the color values between the two points across the rectangle,
bicubically interpolate the colors across a Bezier surface.
Does that make sense?

I guess I also had it in my mind that if I had an existing _geometric_ bezier
patch, that somehow it would be possible to simply define the colors of the 4
fixed corners, and those would get mapped to the geometric coordinates.   Then
the geometric control points would control the bicubic color interpolation
between the color values - avoiding the need to write a whole separate block of
code for the coloring.

I hadn't really though it all the way through, so sorry for any confusion.

But it does suggest that there could be a bicubic WARP where patterns could be
distorted (or image maps corrected) through such a mechanism.

Also, the mesh camera is an interesting idea.  I'm not sure what you mean by the
finish map - but I would imagine it has something to do with the
ray-scene/surface angles?   Like for something simple like specular reflection?
That I simply don't know.
Maybe if it were just an experimental feature, use the undistorted mesh camera
to generate the color but the bicubic functions to control the view....
No idea.

[Le Forgeron] Re: An updated povr tarball for Unix/Linux. f6b1... [2062 days 23 hours and 31 minutes ago]

Thu, 27 Aug 2020 03:06:13 GMT

> 
>
https://computergraphics.stackexchange.com/questions/2117/map-a-texture-onto-a-hyperbolic-triangle
> https://medium.com/@philogb/hyperbolic-floors-a2c5445144c6
> https://mediatum.ub.tum.de/doc/1210572/1210572.pdf


An investigation not as pattern but as warp could be interesting.

The early part to answer is: what happen outside the circle.
One answer can be: nothing, outside the circle, there is no transformation.

Or something different, as suggested in the pdf for poincarrÃ© disk.

It is "of course" to be mainly used with the image pattern, so it is
better from the very start that the reference plane be the same (to
avoid a systematic rotate), and the third coordinates is to be dropped.

So far the "perfect" illustration could be some pedestal table with such
topping, and some chess set on it...
With an outer ring, which implies some layered textures too.

*********

About bezier bicubic patches, I do not so far understand what is the
final purpose of the request. Does it sound like gluing the mesh camera
to a bezier bicubic patch ? (mesh camera or user-function defined camera).
As a raytracing aims at generating pictures, what is a finish map in
that context ?

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2064 days 7 hours and 57 minutes ago]

Tue, 25 Aug 2020 18:40:00 GMT

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

> None can be that important given how long they've not been done! :-)

Well, yes.   There's that.
But one might equally ascribe their non-usage to their non-existence.

Given an easy way to do something, people usually take it.
If faced with the prospect of somehow getting someone somewhere to write a
mapping in source code and provide a new release - or - just writing some "good
enough" pseudo-mapping or function-mapping, then maybe that's what's been done.
No idea how many people (would have) use(d) those other types of maps, but
possibly that would tip the scales the other way.

It's always hard to speculate about these things accurately.  ;)

> Guessing a  at meaning/application, the parabolic I suppose might
> occasionally be of use - parabolas.

I guess maybe there might be further use with parabolic mirrors, cameras, and -
more specifically - telescopes.

https://www.eso.org/sci/facilities/paranal/telescopes/vlti/tuto/tutorial_introduction_to_stellar_interf.pdf

> Taking the hyperbolic to mean
> non-linear in some aspect of other usually linear mappings, that I guess
> that would end up as a set of 'hyper' mappings for linear, spherical,
> etc.

I looked - it seems like they might be very useful and fun for Escher fans.
M. Grimbert might be interested, given he seems to be the master of tilings.
I'm guessing/speculating that these mappings (Poincare disks, etc) might have
practical engineering / scientific use in physics, Finite Element Methods, fluid
dynamics, etc?

https://computergraphics.stackexchange.com/questions/2117/map-a-texture-onto-a-hyperbolic-triangle
https://medium.com/@philogb/hyperbolic-floors-a2c5445144c6
https://mediatum.ub.tum.de/doc/1210572/1210572.pdf

Or maybe it has specific application to cartography and map projections?
https://en.wikipedia.org/wiki/Squeeze_mapping

It might also be related to a catadioptric omnidirectional camera mapping, like
that used with a hyperbolic convex mirror.
https://link.springer.com/content/pdf/10.1007%2F978-3-642-02921-9_26.pdf

And this leads me to believe that they are all related:
http://roguetemple.com/z/hyper/models.php

> Piriform suppose might have been aimed at two element blobs or
> something?

Possibly.   No idea why it was desired in v 1 of all things, and the only places
I find it aside from pure math sites, is references for POV-Ray (with Mike
Williams bridging that gap)
https://mathworld.wolfram.com/PiriformCurve.html
https://mathworld.wolfram.com/PiriformSurface.html

>
> My up front issue with all more complicated mappings - and with the more
> complicated shape uv_mapping options - is one should first and foremost
> work out how the maps can easily be created in POV-Ray(1). Or, know of
> some standard external 'standard' like the light probe angular mapping
> added to v3.8. Otherwise, you've got some feature you can 'advertise'
> and which might look great for a demo or two, but in the end it's a
> feature pretty much nobody uses.
>
> (1) - Matching cameras, an interactive painting capability, ...
>
> Aside: Most any complicated mapping can be accomplished today via
> functions - though it might not be easy to get right, as you well know.

Of course.   But sometimes these things inexplicably take on a life of their
own.  And during the course of investigating them simply out of curiosity,
novelty, or someone's specialized interest or based solely on the challenge of
doing it - we uncover bugs (!) and discover interesting new things that we might
never have thought of or even known were possible.

Just figured I'd ask - because obviously _someone_ thought they were important
enough to assign a mapping slot for them early on.

##############################################################################

Now, given the fact that we have uv-mapping for Bezier bicubic patches, and the
source code to create the patch from the corners and control points:

Do we think it would be a lot of work to add a feature where
colors/pigments/textures/finishes could be specified at the corners of a Bezier
patch, and a pattern / map would be generated based on the patch?
https://www.ibiblio.org/e-notes/Splines/color3d.html
(I didn't SEE such a thing in HGpovray38, but I might have missed it)

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2064 days 15 hours and 11 minutes ago]

Tue, 25 Aug 2020 11:26:11 GMT

On 8/24/20 1:35 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
> Are these mapping types still in need of development?
> 

None can be that important given how long they've not been done! :-)

Guessing a  at meaning/application, the parabolic I suppose might 
occasionally be of use - parabolas. Taking the hyperbolic to mean 
non-linear in some aspect of other usually linear mappings, that I guess 
that would end up as a set of 'hyper' mappings for linear, spherical, 
etc. Piriform suppose might have been aimed at two element blobs or 
something?

My up front issue with all more complicated mappings - and with the more 
complicated shape uv_mapping options - is one should first and foremost 
work out how the maps can easily be created in POV-Ray(1). Or, know of 
some standard external 'standard' like the light probe angular mapping 
added to v3.8. Otherwise, you've got some feature you can 'advertise' 
and which might look great for a demo or two, but in the end it's a 
feature pretty much nobody uses.

(1) - Matching cameras, an interactive painting capability, ...

Aside: Most any complicated mapping can be accomplished today via 
functions - though it might not be easy to get right, as you well know.

Bill P.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2065 days 8 hours and 57 minutes ago]

Mon, 24 Aug 2020 17:40:00 GMT

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

> I ran across the following in the v1.0 source code the other day while
> trying to understand the history of something:
>
> /* Image/Bump Map projection methods */
> #define PLANAR_MAP      0
> #define SPHERICAL_MAP   1
> #define CYLINDRICAL_MAP 2
> #define PARABOLIC_MAP   3
> #define HYPERBOLIC_MAP  4
> #define TORUS_MAP       5
> #define PIRIFORM_MAP    6
> #define OLD_MAP         7

VERY cool  :)
It's more than clipka uncovered.
So at least that answers a 6-year-old question.  :D

http://news.povray.org/povray.binaries.images/message/%3C5438051b%241%40news.povray.org%3E/#%3C5438051b%241%40news.povr
ay.org%3E

Are these mapping types still in need of development?

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2065 days 16 hours and 1 minute ago]

Mon, 24 Aug 2020 10:35:59 GMT

On 8/23/20 1:38 PM, Bald Eagle wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
...
> 
> Wih respect to image_map specifically, any guesses as to what the missing map
> types were supposed to be?  :D
> 

I ran across the following in the v1.0 source code the other day while 
trying to understand the history of something:

/* Image/Bump Map projection methods */
#define PLANAR_MAP      0
#define SPHERICAL_MAP   1
#define CYLINDRICAL_MAP 2
#define PARABOLIC_MAP   3
#define HYPERBOLIC_MAP  4
#define TORUS_MAP       5
#define PIRIFORM_MAP    6
#define OLD_MAP         7

I guess v3.8's type 7 (angular light probe?) took OLD_MAP's slot :-).

The documentation has forever said types 3 & 4 are under development, 
but I've never spotted any actual code indicating this ever true beyond 
an intent. FWIW.

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2066 days 6 hours and 32 minutes ago]

Sun, 23 Aug 2020 20:05:00 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> ...
> 2. sysconf .... Initially I thought you wanted access to sysconf, but it
> seems to only be a model.

yes, just a function with an interface like 'sysconf()'.  Bald Eagle put it
better than I could.

> ...
> To misname things is to add to the unhappiness of the world.

agree, and yet, finding "good" descriptive names is never easy (for me, anyway).

regards, jr.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2066 days 8 hours and 57 minutes ago]

Sun, 23 Aug 2020 17:40:00 GMT

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

> You know what is bad with such idea ?
> 1. Look at the map type in image_map: using number instead of explicit
> good name is painful, even when Constants.inc provides some name afterward.

Yes.  I would agree that a good (but SHORT) name would be best.
But I have also come to value the ability to refer to things numerically, so
that I can loop through a collection of things easily - we people love
descriptive, meaningful names - computers love numbers.

Wih respect to image_map specifically, any guesses as to what the missing map
types were supposed to be?  :D

> Initially I thought you wanted access to sysconf, but it
> seems to only be a model.

I think he was interested in having a "povray system function" that would be
able to return a number of different system / environment / configuration values
- LIKE sysconf.
So perhaps some of the internal epsilon values, memory available, threads used,
etc.   Someone might want to annotate their render or generate a text file that
gets post-render bundled with their render for documentation purposes.
Development, debugging, documenting - and they may want/need to do that with a
programmable function - like if they have 3000 frames - and avoid having to drag
another software/OS tool (and learning curve) into the mix.

> To misname things is to add to the unhappiness of the world.

Yeah, brother.  No truer words were ever spoken.  Say what you mean, and mean
what you say. (Or at least try as much as possible/practical)

[Le Forgeron] Re: An updated povr tarball for Unix/Linux. f6b1... [2066 days 9 hours and 27 minutes ago]

Sun, 23 Aug 2020 17:10:37 GMT

Le 19/08/2020 Ã  21:27, jr a Ã©critÂ :
> hi,
> 
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Le 04/08/2020 ÃƒÂ  10:26, Le_Forgeron a
ÃƒÂ©critÃ‚Â :
>>> Ok, I note there is one remaining point that could be interesting:
>>> getting the current number of parsed tokens.
>>> Does not seem so urgent as a change.
>>
>> For the curious, the value is in parser/parser.h : mTokenCount
>>
>> Now, can someone provide a good name for the SDL to return that value ?
> 
> some new function modelled on 'sysconf(3)' would be cool, with 'mTokenCount'
> just one of the argument values, perhaps.
> 
> 

You know what is bad with such idea ?
1. Look at the map type in image_map: using number instead of explicit
good name is painful, even when Constants.inc provides some name afterward.

http://wiki.povray.org/content/Reference:Image_Map

2. sysconf is a pain to use: you always need to be on the local system
to be sure to get what you ask (the man page of sysconf is using
symbolic constants, which do not translate at all between systems once
compiled). Initially I thought you wanted access to sysconf, but it
seems to only be a model.

3. it is too open: there is no usable specification.
It is like "add a foo(bar) function which return mTokenCount when bar is 3"
Why having such function ? What would be the common part with the value
returned when bar is 5 ?
Also Povray loves floating point values, and hates integer, so what is
the meaning of foo(3.4) ?
It reminds me far too much of the poke & peek tables in the 80's computers.

To misname things is to add to the unhappiness of the world.

[Le Forgeron] Re: An updated povr tarball for Unix/Linux. f6b1... [2066 days 17 hours and 14 minutes ago]

Sun, 23 Aug 2020 09:23:08 GMT

Le 20/08/2020 Ã  00:22, Bald Eagle a Ã©critÂ :
> Le_Forgeron <jgr### [at] freefr> wrote:
> 
>> Now, can someone provide a good name for the SDL to return that value ?
> 
> token_count
> tokens_current
> parsed_tokens
> object_tokens
> parser_tokens
> current_tokens
> tokens_now()
> 
> HowMuchStuffIHaveParsedSoFar
> 
> :D
> 
Adopted "parsed_tokens"


=======
#version 3.8;
global_settings {assumed_gamma 1.0}
#include "colors.inc"
#default{ finish{ ambient 0.1 diffuse 0.9 }}


light_source { <100,1000,-1000>, White}

camera { location <0,-1,-16>
         right    x*image_width/image_height
         angle 35
         look_at <0,-1,0>
       }

plane{-z,-10  pigment{checker color rgb<1,1,1>*0.8 color rgb<1,1,1>} }

#declare String1=concat("parsed_tokens =", str(parsed_tokens,0,0));


text{ internal 1, "Parser info", 0.3, 0 pigment{Blue*0.7} translate
-4.5*x+1.5*y }
text{ internal 1, String1, 0.3, 0 pigment{Red*0.7} translate -4.5*x }
#declare String2=concat("parsed_tokens =", str(parsed_tokens,0,0));
#declare String3=concat("parsed_tokens =", str(parsed_tokens,0,0));
text{ internal 1, String2, 0.3, 0 pigment{Red*0.7} translate -4.5*x -1.5*y }
text{ internal 1, String3, 0.3, 0 pigment{Red*0.7} translate -4.5*x -3*y }

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2070 days 4 hours and 12 minutes ago]

Wed, 19 Aug 2020 22:25:00 GMT

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

> Now, can someone provide a good name for the SDL to return that value ?

token_count
tokens_current
parsed_tokens
object_tokens
parser_tokens
current_tokens
tokens_now()

HowMuchStuffIHaveParsedSoFar

:D

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

Wed, 19 Aug 2020 19:30:00 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 04/08/2020 Ã  10:26, Le_Forgeron a Ã©critÂ :
> > Ok, I note there is one remaining point that could be interesting:
> > getting the current number of parsed tokens.
> > Does not seem so urgent as a change.
>
> For the curious, the value is in parser/parser.h : mTokenCount
>
> Now, can someone provide a good name for the SDL to return that value ?

some new function modelled on 'sysconf(3)' would be cool, with 'mTokenCount'
just one of the argument values, perhaps.


regards, jr.

[Le Forgeron] Re: An updated povr tarball for Unix/Linux. f6b1... [2070 days 7 hours and 55 minutes ago]

Wed, 19 Aug 2020 18:41:50 GMT

Le 04/08/2020 Ã  10:26, Le_Forgeron a Ã©critÂ :
> Ok, I note there is one remaining point that could be interesting:
> getting the current number of parsed tokens.
> Does not seem so urgent as a change.

For the curious, the value is in parser/parser.h : mTokenCount

Now, can someone provide a good name for the SDL to return that value ?

[jr] Re: povr render 'optics.pov' [2074 days 7 hours and 37 minutes ago]

Sat, 15 Aug 2020 19:00:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I broke the checker pattern on March 29th. ;-)
> ...
> When I updated EPSILON ...  it was mostly working anyway. ...

:-)

> ...
> Anyway, thanks again for spotting this / testing.

anytime.  (while I can, 'povr' permitting.  ;-))


regards, jr.

[William F Pokorny] Re: povr render 'optics.pov' [2074 days 8 hours and 21 minutes ago]

Sat, 15 Aug 2020 18:16:43 GMT

On 8/15/20 12:35 PM, William F Pokorny wrote:
> On 8/15/20 11:21 AM, jr wrote:
...
> 
> I see it too in all my recent povr versions. It was OK in versions early 
> this year, so something I've done between then and early July.
> 
> I'll do a binary search - compile/run through my commits to find the 
> commit causing the problem. FYI. No photons required to see it.
> 

I broke the checker pattern on March 29th. ;-)

---
There has been a defined EPSILON value floating around in the code for a 
long time. Over the years it sort of got used any time folks had the 
thought, "I need an epsilon value." All to often it was (at 1e-10) a 
non-optimal value to use.

I've been cleaning these up; mostly breaking them into two buckets after 
determining what I thought good values numerically while doing my solver 
work. A treat this as zero epsilon and a good supportable intersection 
depth tolerance. The former I called gkDBL_epsilon which is a little 
larger than the C++ DBL_epsilon macro value and the other is called 
gkMinIsectDepthReturned(1).

When I updated EPSILON in the checker pattern, I used gkDBL_epsilon when 
I should've used gkMinIsectDepthReturned. Yes, this is an intersection 
with a plane, low order and more accurate - it was mostly working 
anyway. The actual supportable value is certainly between the two values 
I settled on. But, going with the standard gkMinIsectDepthReturned in 
checker unless something 'else' breaks.

Aside: Yes, sometimes you really need somewhat unique 'epsilon' values. 
When I was cleaning up the tiling patterns for isosurface use, I ran 
across a collection of such values where someone had commented that a 
C++ macro should perhaps be used. But in testing each, every one of 
those needed to be what they were to the order of magnitude. Jerome had 
done his homework! :-)

Anyway, thanks again for spotting this / testing.

Bill P.

[jr] Re: povr render 'optics.pov' [2074 days 9 hours and 7 minutes ago]

Sat, 15 Aug 2020 17:30:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/15/20 11:21 AM, jr wrote:
> > an unrelated thread made me render the 'scenes/advanced/optics.pov' file.  with
> > 'povr' I get a strange "band" in the lower part of the image.  attached.
>
> Thanks jr (and Jerome)!

no sweat.  :-)

> ...
> (jr, If you are looking for a scene with a parabolic mirror I recall
> Warp doing one some years ago which he posted. I thought had a copy
> somewhere, but I cannot find it at the moment. He might have used a
> polynomial for the shape.)

that should probably be addressed to 'ttyUSB0'.  I was simply curious, following
Le Forgeron's reply to him/her.


regards, jr.

[William F Pokorny] Re: povr render 'optics.pov' [2074 days 10 hours and 2 minutes ago]

Sat, 15 Aug 2020 16:35:10 GMT

On 8/15/20 11:21 AM, jr wrote:
> hi,
> 
> an unrelated thread made me render the 'scenes/advanced/optics.pov' file.  with
> 'povr' I get a strange "band" in the lower part of the image.  attached.
> 

Thanks jr (and Jerome)!

I see it too in all my recent povr versions. It was OK in versions early 
this year, so something I've done between then and early July.

I'll do a binary search - compile/run through my commits to find the 
commit causing the problem. FYI. No photons required to see it.

(jr, If you are looking for a scene with a parabolic mirror I recall 
Warp doing one some years ago which he posted. I thought had a copy 
somewhere, but I cannot find it at the moment. He might have used a 
polynomial for the shape.)

Bill P.

[jr] Re: povr render 'optics.pov' [2074 days 10 hours and 22 minutes ago]

Sat, 15 Aug 2020 16:15:00 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 15/08/2020 Ã  17:21, jr a Ã©critÂ :
> > an unrelated thread made me render the 'scenes/advanced/optics.pov' file.  with
> > 'povr' I get a strange "band" in the lower part of the image.  attached.
>
> Only for povr, at least hgpovray38 is clear of such noise, and so I
> presume official master (3.8) too.

yes, the alpha.10064268 output is ok.  have not yet installed 'bigarade' on this
machine, so good to know, thanks.


regards, jr.

[Le Forgeron] Re: povr render 'optics.pov' [2074 days 10 hours and 45 minutes ago]

Sat, 15 Aug 2020 15:52:30 GMT

Le 15/08/2020 Ã  17:21, jr a Ã©critÂ :
> hi,
> 
> an unrelated thread made me render the 'scenes/advanced/optics.pov' file.  with
> 'povr' I get a strange "band" in the lower part of the image.  attached.
> 
> 
> regards, jr.
> 

Only for povr, at least hgpovray38 is clear of such noise, and so I
presume official master (3.8) too.

[jr] povr render 'optics.pov' [2074 days 11 hours and 12 minutes ago]

Sat, 15 Aug 2020 15:25:00 GMT

hi,

an unrelated thread made me render the 'scenes/advanced/optics.pov' file.  with
'povr' I get a strange "band" in the lower part of the image.  attached.


regards, jr.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2085 days 15 hours and 12 minutes ago]

Tue, 4 Aug 2020 11:25:01 GMT

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

> And nobody looked at hgpovray:

I have and I do.   I have a tab open in my browser right now:
https://github.com/LeForgeron/povray/releases/tag/v3.8.0.alpha%2BHg.228.Jasmin
because it's going to get installed on my "new" laptop.

But I was mentioning this with an eye toward implementing it in official
pov-ray, the argument being, "If the code exists, and it works, and no one has
discovered any bugs - then what are the excuses left to NOT implement it?"
And if hgpovray has it AND povr has it, ....?

> Only if such "object" could be queried. It would have to distinguish
> between points (3D vector) and normal (also 3D vector) at a given location.

No, because it would be a proper object.
point {<vector>}
Then you could do translate <-1, 3, 9> and rotate -x*45
and then do a standard min_extent max_extent "query" on its location.

This would be useful for collections of points in a union that define important
points in/on an object.  Like a rotating gear or a chain or whatever one might
like to have a usable data point to plug into an equation.

> On the other hand, the answer of Tor is fine: you can already have a
> transform object and process vectors in it.

You can, but it's --- awkward.   I _can_ do certain things with macros and
functions, but it's not anywhere near as straightforward as if I were just
driving forward with aliases and vector functions.

> That could be considered, a bit like "now", the variable which returns
> the current number of seconds since 2000-1-1 0:0:0 GMT.

Yes, sure - that makes sense.

> * number of parsed token is a local data, just to find it in the code
> (as it is currently reported by the parser, it must exist somewhere).

Well it ticks off at the bottom of qtpovray and presumably windows, so I just
assumed that it was available at any given moment.

> * current memory usage, I have a problem: how do you get that piece of
> information, in a portable/Posix way ?

IIRC, the windows editor displays that information during parsing, so someone
has already done it?

> If you want to protect your system from memory exhaustion, it is better
> to ask the system to do it, or delegate to some tools between the system
> and povray.

Yes, but for some people, that's a whole other skill set and learning curve and
time sink that takes away from writing the scene.   It was just a small
suggestion that I thought could be useful if it could be trivially implemented.

> There is already "transform" & "matrix" , but they are targeted to 3D
> operations, using weighted coordinates (4x4, but you do not get to
> specify the last column)

Yes - I meant in a general sense.  Data structures and tools where one could
create normal mathematical matrices and do all of the usual matrix math
operations.   I know that we have _some_ macros for that, and I have written
quite a few of my own, but having a more complete, formal set of tools for this
would be nice - there are a lot of people who use povray for math and graphics,
and want to use it as a tool to do creative work and understand an
illustrate/demonstrate the underlying processes.

> Convolution matrices are 2D filters, this is nothing related to our
> matrices, it could be a totally new domain of exploration.

They are.  I envision a lot of interesting things that people could do, using
them as image_map modifiers in order to process terrain and even procedural
pigment patterns.

> > 1D and 2D fast Fourier transforms.
> > Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
> > http://paulbourke.net/miscellaneous/dft/
> >
>
> Und ich sage "Warum ?"

as did clipka.

> Fourier transforms are used with sampling (and fixed number of values).
> It is lovely in Jpeg and other compressions, but what would be the usage
> in a 3D rendering program ?

Because povray is uniquely a DATA driven rendering software where things are
made programmatically, not with a modeler.  And of course a vast amount of the
data we deal with is procedural.  Patterns.  Signals, if you will.  And so the
single-most useful signal-processing algorithm ever conceived could (and would)
be used to create, analyze, and filter data sets for use in making patterns, and
creating the necessary geometry to be textured and rendered.
People have already played with making object shapes with fourier.   jpg has
color banding that someone may want to know the periodicity of.   procedural
patterns and various fractal textures may have repeats that one may need to know
the frequency of in order to avoid/hide.   Procedural patterns are _patterns_
And everything we do is based on patterns.   Chris Cason mentioned that people
use povray as part of their workflow.  I corresponded somewhat recently with
someone who was in fact using fourier to do work on x-ray crystallographic data.
 Mathematicians and scientists would surely find this otherwise ubiquitous tool
useful and we may get new users who discover povray itself - not as a and
end-of-pipeline rendering tool, but as a curiosity and hobby.   This is how we
get new people and ideas.   Lots of scientific data gets processed and
visualized with povray - it's information.  Signals.
I almost see this as being akin to "of what use would something like Perlin
noise be to 3D graphics...?"

> Wavelet (compression) also had its time of hype, yet it seems unrelated
> to 3D rendering.

Unfamiliar with that.

> Does not seem so urgent as a change.

These are suggestions for the interested to consider.   Not any "urgent"
features that I'm hounding anyone to do right now.

[Le Forgeron] Re: An updated povr tarball for Unix/Linux. f6b1... [2085 days 18 hours and 11 minutes ago]

Tue, 4 Aug 2020 08:26:26 GMT

Le 03/08/2020 Ã  19:43, Bald Eagle a Ã©critÂ :
> I haven't had much time to explore all of the forks and other projects - but
> while they are under development, maybe I could throw some old and new ideas
> out.
> 
> SO many people have asked to have values like the camera location be available.
> 

And nobody looked at hgpovray:

http://wiki.povray.org/content/User:Le_Forgeron/cameras#Access_to_camera_information

> http://wiki.povray.org/content/User:Le_Forgeron/cameras#Access_to_camera_information




> As it is a vector, having the ability to have such a value be translated,
> rotated, etc. and then queried for the result reminds me that having a point or
> vector object that can be manipulated using standard SDL commands would be very
> useful for a lot of folks who need to do that kind of thing.

Only if such "object" could be queried. It would have to distinguish
between points (3D vector) and normal (also 3D vector) at a given location.

On the other hand, the answer of Tor is fine: you can already have a
transform object and process vectors in it.

> 
> Working on Yadgar's code, I realized that it might be an interesting and useful
> thing to be able to access the current memory usage and the current number of
> tokens parsed - for reporting, but also to define a bailout so as not to crash
> the system, etc.

That could be considered, a bit like "now", the variable which returns
the current number of seconds since 2000-1-1 0:0:0 GMT.

* number of parsed token is a local data, just to find it in the code
(as it is currently reported by the parser, it must exist somewhere).

* current memory usage, I have a problem: how do you get that piece of
information, in a portable/Posix way ?
** Linux/Unix could use sysinfo()
** Windows could use GetProcessMemoryInfo(GetCurrentProcess(), ... )
** Mac could use task_info(mach_task_self(), ... )

If you want to protect your system from memory exhaustion, it is better
to ask the system to do it, or delegate to some tools between the system
and povray.



> 
> Obviously there have been many requests for vector functions, and that leads me
> to bring this up:
> #macro eval_pigment(pigm, vec)
>     #local fn = function { pigment { pigm } }
>     #local result = (fn(vec.x, vec.y, vec.z));
>     result
> #end
> 
> Somehow this magically returns a vector quantity, rather than a scalar.  :O
> 
> Matrix objects would be very nice for certain 3D graphics calculations and
> transformations.  Maybe a matrix convolution function for image processing.  I
> can see this being closely related to the recent work on function gradients as
> well.

There is already "transform" & "matrix" , but they are targeted to 3D
operations, using weighted coordinates (4x4, but you do not get to
specify the last column)

Convolution matrices are 2D filters, this is nothing related to our
matrices, it could be a totally new domain of exploration.

> 
> 1D and 2D fast Fourier transforms.
> Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
> http://paulbourke.net/miscellaneous/dft/
> 

Und ich sage "Warum ?"

Fourier transforms are used with sampling (and fixed number of values).
It is lovely in Jpeg and other compressions, but what would be the usage
in a 3D rendering program ?

Wavelet (compression) also had its time of hype, yet it seems unrelated
to 3D rendering.


> Just throwing out ideas, as these are inherently source code edits and
> additions.
> 
> 

Ok, I note there is one remaining point that could be interesting:
getting the current number of parsed tokens.
Does not seem so urgent as a change.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2085 days 18 hours and 37 minutes ago]

Tue, 4 Aug 2020 08:00:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/2/20 7:33 PM, jr wrote:
> > ...
> > another "interesting" thing is the output of 'ps'.  a big difference in the
> > virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
> > while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
> > reads 1.
> ...
> First the obvious, might you have been looking at 'povr' the script and
> not the real running povray command? Otherwise I'm not completely sure.
> ...

thanks, yes.  I forgot/overlooked that the executable is invoked from a script.
:-(


regards, jr.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2086 days 1 hour and 47 minutes ago]

Tue, 4 Aug 2020 00:50:01 GMT

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

> I'm lurking around in here in periods, but I seldom have as much time to
> contribute as I would like.

Of course.  I hope you enjoy what you do and your field of work is flourishing.

Most of my work gets done in fits and starts and flashes of inspiration.  Rest
assured that much of what you have done to help myself and others clarify key
concepts and make it over hurdles we were struggling with has been of great
value.   Every snippet of code, equation, macro, or even a single 9-character
line of code is something to be used, learned from, and transferred on to others
climbing the same ladder.

> What is happening here is often interesting and
> thought provoking. And sometimes very nice images appear ! So it is very good
> that you and others keep this forum alive over time.

Indeed, there is still development happening across the spectrum - from
fundamental equations, algorithms, and other under-the-hood work to the
glistening final renders of stalwarts and masters.

> All is well here, thank you, except, of course, from the COVID-19 pandemic.
> The Corona virus has not (yet) caused such big problems here in Norway as it has
> in many other parts of the world. I hope all is well with you too Bill.

It all seems to be part of the cunning game taking place on the Grand
Chessboard.  The way I see it, "COVID-19" hasn't created any problems over and
above any of the other diseases that have ever arisen over the years, but
certainly the [over]reactions to it HAVE.

All is never "well" - but I have learned from many of the people who have
offered me insight and wisdom over the years that adversity and a bit of
hardship keep the mind and body healthy.

"...technology alone didn't allow humans to go to Madagascar, to Australia.
Neanderthals built boats too. Instead, he says, there's "some madness there. How
many people must have sailed out and vanished on the Pacific before you found
Easter Island? I mean, it's ridiculous. And why do you do that? Is it for the
glory? For immortality? For curiosity? And now we go to Mars. We never stop."
It's ridiculous, foolish, maybe? But it was the Neanderthals who went extinct,
not the humans.”"

“Maybe it's only a fool who will perilously journey out to what might not be
there. And maybe it's only a fool who will ask about supertasks, about infinity.
But if you want to solve problems, you don't just solve the ones that are there,
you find more and make more and go after the impossible ones; fostering a love
and obsession with problems is how you solve problems. Antoine de Saint-Exupéry
wasn't a mathematician, but his advice fits nicely here. If you want to build a
ship, don't drum up people to collect wood and don't assign them tasks and work,
but rather teach them to long for the endless immensity of the sea."

- Michael Stevens

[Tor Olav Kristensen] Re: An updated povr tarball for Unix/Linux. f6b1... [2086 days 2 hours and 52 minutes ago]

Mon, 3 Aug 2020 23:45:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> Good to see you around and poking your head in.    I hope all is going well in
> your part of the world, and you have been finding ways to enjoy yourself amidst
> - everything.

I'm lurking around in here in periods, but I seldom have as much time to
contribute as I would like. What is happening here is often interesting and
thought provoking. And sometimes very nice images appear ! So it is very good
that you and others keep this forum alive over time.

All is well here, thank you, except, of course, from the COVID-19 pandemic.
The Corona virus has not (yet) caused such big problems here in Norway as it has
in many other parts of the world. I hope all is well with you too Bill.

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

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2086 days 6 hours and 12 minutes ago]

Mon, 3 Aug 2020 20:25:03 GMT

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

> Bill,
>
> Have you seen these sections in the documentation ?
>
> Declaring User-Defined Vector Functions
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_4
>
> Declaring User-Defined Color Functions
> https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_5

Aye, I have, I have used the spline functions, and intuitively knew about the
pigment functions, but have spent so much time with scalar-only functions, that
it just struck me as --- odd and unexpected.


Good to see you around and poking your head in.    I hope all is going well in
your part of the world, and you have been finding ways to enjoy yourself amidst
- everything.

[Tor Olav Kristensen] Re: An updated povr tarball for Unix/Linux. f6b1... [2086 days 7 hours and 47 minutes ago]

Mon, 3 Aug 2020 18:50:01 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
>...
> Obviously there have been many requests for vector functions, and that leads me
> to bring this up:
> #macro eval_pigment(pigm, vec)
>     #local fn = function { pigment { pigm } }
>     #local result = (fn(vec.x, vec.y, vec.z));
>     result
> #end
>
> Somehow this magically returns a vector quantity, rather than a scalar.  :O

Bill,

Have you seen these sections in the documentation ?

Declaring User-Defined Vector Functions
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_4

Declaring User-Defined Color Functions
https://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_8_5

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

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2086 days 8 hours and 52 minutes ago]

Mon, 3 Aug 2020 17:45:00 GMT

I haven't had much time to explore all of the forks and other projects - but
while they are under development, maybe I could throw some old and new ideas
out.

SO many people have asked to have values like the camera location be available.

As it is a vector, having the ability to have such a value be translated,
rotated, etc. and then queried for the result reminds me that having a point or
vector object that can be manipulated using standard SDL commands would be very
useful for a lot of folks who need to do that kind of thing.

Working on Yadgar's code, I realized that it might be an interesting and useful
thing to be able to access the current memory usage and the current number of
tokens parsed - for reporting, but also to define a bailout so as not to crash
the system, etc.

Obviously there have been many requests for vector functions, and that leads me
to bring this up:
#macro eval_pigment(pigm, vec)
    #local fn = function { pigment { pigm } }
    #local result = (fn(vec.x, vec.y, vec.z));
    result
#end

Somehow this magically returns a vector quantity, rather than a scalar.  :O

Matrix objects would be very nice for certain 3D graphics calculations and
transformations.  Maybe a matrix convolution function for image processing.  I
can see this being closely related to the recent work on function gradients as
well.

1D and 2D fast Fourier transforms.
Paul Bourke already has 2D in-place FFT code in c++ posted on his site.
http://paulbourke.net/miscellaneous/dft/

Just throwing out ideas, as these are inherently source code edits and
additions.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2086 days 12 hours and 57 minutes ago]

Mon, 3 Aug 2020 13:40:01 GMT

On 8/2/20 7:33 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 7/29/20 2:16 PM, jr wrote:
>> ...
>> regarding that, I did a
>>> 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
>>> call (including surrounding conditional) the only thing that would need to be
>>> added to allow the _f9bc4ef7 version to function safely wrt X11?
>>
>> As safely as the newer release, yes.
>> ...
> 
...
> 
> another "interesting" thing is the output of 'ps'.  a big difference in the
> virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
> while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
> reads 1.
> 

Thank you for information on parsing and render times! I welcome all the 
feedback.

The 2% of normal POV-Ray memory use is surprising/unlikely as is the 1 
thread - given the actual results.

First the obvious, might you have been looking at 'povr' the script and 
not the real running povray command? Otherwise I'm not completely sure.
Something with animation perhaps. Animations do drop back to one thread 
when parsing and memory use would drop there too - initially.

If using photons, the thread use is different in that phase too.

Mostly these days I use top (linux) or htop (Raspberry (now with 8gb 
models and a promise of a true 64bit OS!)). For an artificially long 
running biscuit scene, I do see smaller sizes with top when using -y x11 
- which is not too surprising.

Virtual memory(a) KiB
     1120456 -> 754484 ---> -32.66%
Real memory
      47576  ->  32372 ---> -31.96%

(a) - always a little 'wide' of the mark in my experience.

In news to me. When I look at threads specifically with 'ps -eLf | grep 
povr' I do see a difference between SDL1.2 (v38) and SDL2.0 (povr) in 10 
to 14 active threads on my 2 core 4 thread machine. For me, POV-Ray 
proper normally runs with 10 threads in the final render phase. Six of 
threads are mostly idle. For reasons unknown to me, SDL2.0 has 4 more 
mostly idle threads? A question for the 'someday-maybe look at it 
further' list. :-)

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2087 days 2 hours and 57 minutes ago]

Sun, 2 Aug 2020 23:40:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/29/20 2:16 PM, jr wrote:
> ...
> regarding that, I did a
> > 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> > call (including surrounding conditional) the only thing that would need to be
> > added to allow the _f9bc4ef7 version to function safely wrt X11?
>
> As safely as the newer release, yes.
> ...

not sure you will be as pleased as I am, but I've successfully downgraded to a
patched _f9bc4ef7.  I've used it to re-run the animation, no problems.  and it
is, for that code, faster than stock POV-Ray.  for the parsing, 'povr' needed
around 13.2 seconds per frame, while the alpha took around 13.8; for a 360 frame
animation, that alone has saved more than three minutes.  the total times (360
frames) were:
      alpha.10064268     povr
real    204m9.135s     181m32.384s
user    547m30.221s    470m55.856s
sys     0m3.471s       0m6.385s

another "interesting" thing is the output of 'ps'.  a big difference in the
virtual memory size, 'povr' barely 2% of POV-Ray's size.  and, puzzling this,
while the thread count ('nlwp') for POV-Ray fluctuates (6 to 10), 'povr's always
reads 1.

and regarding my previous post, I feel I should not have just given the car
analogy and left it at that; another instance of (me) communicating poorly.  I
guess it is, for me, about choice.  if, in the documentation, early and
prominently, there was a section regarding "interoperability", a paragraph on
name collisions and concerns, and one on the naming convention chosen to
(almost) always prevent name clashes, that should suffice. in my case, virtually
all SDL code I write is exclusively for my own consumption/entertainment, hence
my .. feeling bolshie re mandated uppercase, I guess.  :-)  if I write something
I think might be useful and decide to publish, then I'd have no objection to
writing that code to adhere to given guidelines. so, I hope the feature can be
made a selectable option, because I'd like to keep following along on the ..
'povr' journey.  :-)  (I guess I might even use the feature, to check whether
the code "passes")

regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 9 hours and 42 minutes ago]

Sat, 1 Aug 2020 16:55:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/31/20 4:19 AM, jr wrote:
> > ...
> > cannot say the same.  guess I'm "allergic" to uppercase.  :-)
> >
> > (could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)
> >
>
> Maybe in the near term, but the whole idea is to offer a way to code
> function and macro parameters which will never collide. This method only
> works if people cannot turn off the case checking.
>
> I don't think there is any magic here. Name spaces, or whatever method,
> any fix(es) for indentifier name collisions will require changes to
> existing code and coding habits.

while I agree that the "method only works if", and that, ultimately, "existing
code and coding habits" would (will?) need to change as part of a process, I
found myself thinking about a car analogy, the time when what are now "classic"
cars had to be retrofitted with seat belts[*]; and I wonder whether, like with
the seat belt, the primary victim of car-based incidents, the pedestrian, will
not actually benefit.  </rant>  (:-))

[*] and since they weren't designed with "attach points" in mind, other problems
arose.

I'll address a couple of other points here too.

> I fact looked to me as if several POV-Ray shipped includes are doing
> pointless includes which of course burns parse time for no reason.

yes.  I now tend to simply cut+paste the one or two bits I need from a given
POV-Ray include file into the scene, to get that efficiency.  Bald Eagle makes a
good point about a "monolithic" include, if we had a stand-alone parser,
conceivably, one could write a scene file "optimiser" using that.

in reply to Le Forgeron you write wrt permissions: "A properly set up
unix/linux/*x system..".  just to add for completeness that unlike past setups,
where Alice and Bob were in the (primary) 'users' group, these days it is common
for Alice and Bob to be in their own respective groups, with 'users' membership
being additional; ie even safer by default (assuming system is set up +
maintained).

and lastly, on the 'system()'/'#fopen' .. speculations.

> The more tangled part is what would a command set supporting directories
> look like. Then we'd have the implementation of those commands,
> documentation and training of users. I saw too jr's suggestion for
> system commands. I don't know...

the .. hankering after :-) a 'system()' function, which would have allowed eg BE
to write "system("mkdir -p new/sub/tree")", was long-term.  but I had my "road
to Damascus" moment when I read BE's post, and now think that modifying '#fopen'
to allow bi-directional access to a command would be both a "sympathetic"
extension of the SDL, and a very useful one in that it would permit (promote?) a
completely different way of writing scene code; you already do something
similar, so can vouch for the "useful" aspect.

regards, jr.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 10 hours and 47 minutes ago]

Sat, 1 Aug 2020 15:50:00 GMT

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

> ... looked to me as if several POV-Ray shipped includes are
> doing pointless includes which of course burns parse time for no reason.

Yes, and some don't have prerequisite include statements for their dependencies.
  I think that the segment of torus object needs something in another shapesN
include file and that include file isn't in the file "header".

Some of the other include files / insert files have some mysterious blocks of
code that I haven't deciphered/translated [yet].  IIRC, FL's analytic geometry
has a few near the end...

I was trying to figure out a way to create a monolithic include file that could
selectively include whatever you specified, but I haven't figured out the best
way to do that.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 11 hours and 12 minutes ago]

Sat, 1 Aug 2020 15:25:01 GMT

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

> The more tangled part is what would a command set supporting directories
> look like.

I don't use any of the shellout commands, but I would imagine it would just be a
call to the "DOS" to create the specified directory.
mkdir "newDirectory"

#CreateDirectory "newDirectory"

The only bell-and-whistle thing I could envision would be opening a file for
writing in a subdirectory that doesn't yet exist, and automagically creating the
necessary directory branches for the file.  Probably wisest to purposefully
enable this feature to guard against simple typographical errors.

> Then we'd have the implementation of those commands,

I'm guessing you mean the actual POV-Ray source code

> documentation and training of users.

Which would be --- 3 or 4 lines of text?  :D
I mean, I know that packages of food come with instructions nowadays, "1. tear
open package 2. remove contents 3. eat" but I'm pretty sure most of it ought to
be "self-evident".

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 11 hours and 43 minutes ago]

Sat, 1 Aug 2020 14:54:45 GMT

On 7/31/20 6:29 PM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
>> ...
> 
> ran into a problem with some code I was sent.
> 
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> 
> regards, jr.
> 
Ah, dang. Thanks!

While I'm working on new inbuilt functions, I use the Wrapper.inc 
include. It's found via my own POVINI variable setting and is used to 
point to a git tracked functions.inc file instead of the normal 
./include directory. The latter is not at the moment code controlled - 
though that's the plan.

In short, Wrapper.inc is a hack that lets me develop without having to 
create a build package on inbuilt function re-compiles. This mistake 
happened when I implemented an inbuilt f_supertorus() and updated the 
existing Supertorus shapes.inc macro to call it over, the old explicit 
function {} isosurface code.

I reviewed the other povr shipped includes just now - and I found one 
other mistake... I'd un-commented, or as likely commented in the wrong 
directory, the const.inc include in rand.inc and it declares 'e' which 
fails the lower case check. That include const.inc isn't needed today 
even in POV-Ray best as I can tell(1).

(1) - I fact looked to me as if several POV-Ray shipped includes are 
doing pointless includes which of course burns parse time for no reason. 

Bill P.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 12 hours and 25 minutes ago]

Sat, 1 Aug 2020 14:12:13 GMT

On 7/31/20 4:19 AM, jr wrote:
> hi,
...
> 
> no, for me it's just[*] the lower/uppercase stuff.  basically, each of my old
> scenes I tried, failed.  I thought about modifying scene code, but since they
> work I'll find it easier not to use (the new version of) 'povr'.
> 
> [*] at present.
> 
>> Are there actual conflicts/problems with the approach; or examples where
>> it's very inconvenient?
> 
> just inconvenient.  eg, to "fix" the scene I used when I ran into the X11
> animation issue, would be a lot of work, made worse by the fact that I got that
> scene from the web, ie it's not even my code.
> 
>> The functionality is still hacked in - because I'm trying it too. :-)
>> But, thus far, I'm liking the behavior.
> 
> cannot say the same.  guess I'm "allergic" to uppercase.  :-)
> 
> (could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)
> 

Maybe in the near term, but the whole idea is to offer a way to code 
function and macro parameters which will never collide. This method only 
works if people cannot turn off the case checking.

I don't think there is any magic here. Name spaces, or whatever method, 
any fix(es) for indentifier name collisions will require changes to 
existing code and coding habits.

Bill P.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 12 hours and 31 minutes ago]

Sat, 1 Aug 2020 14:06:06 GMT

On 7/31/20 12:55 PM, Le_Forgeron wrote:
> Le 31/07/2020 Ã  16:40, jr a Ã©critÂ :
>> hi,
>>
>> "Bald Eagle" <cre### [at] netscapenet> wrote:
>>> ...
...
>> have been thinking about (wishing for) for a 'system()' type function for a long
>> time.  but reading the above made me realise that a modified '#fopen' which
>> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
>> "everything" anyway.  then we could write, eg:
>>
>> #fopen FP "| program" rdwr
>>
>> to communicate with 'program', making creating a directory, all sorts of stuff,
>> easy and convenient.  for instance write some calculated parameters to 'program'
>> and read back new, derived values.
...
> 
> "Danger Will Robinson"
> 
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.
> 

Though I've used *x systems for a long time, I make no claims on being a 
system image / os expert. I get that there might have been reasons for 
the io restrictions long ago, but how much protection do the io 
restrictions 'really' offer these days?

A properly set up unix/linux/*x system - whether POV-Ray is installed or 
not - already sets permissions which prevent regular users from reading 
and writing system directories and files.

Excepting, when they are allowed to run as root, in which case they 
already have an infinite number of ways to corrupt the system. And, as 
root, they can even do it using POV-Ray too as it ships/is-packaged today.

On systems, true multi-user or not, a regular user can fill up /tmp for 
example. They can chew up all the real ram, perhaps even all the swap 
with enough time (assuming the system admins are not running monitors 
which kill bad acting processes).

I look at our io restrictions and I think they likely cause as many 
users problems as they solve(1), while making it only a little easier 
for POV-Ray as an entity to say "it's unlikely POV-Ray wiped out your 
system."

(1) - When users or well intention-ed system admins prevent folks from 
being able to read and write where they should be able to read and write.

What am I missing?

Bill P.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2088 days 13 hours and 21 minutes ago]

Sat, 1 Aug 2020 13:16:05 GMT

On 7/30/20 8:44 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Just back from a few days at real life. Back at povr for real tomorrow -
>> or the day after. Ahead of me getting back...
> 
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
> 
> #write creates a file.  Can we create a directory by a similar means?
> Just something to think about.
> 

Yes, and no security issue with unix/linux/*x at least(1).

(1) - Maybe some obscure ways to disable a file system if one works at it.

The more tangled part is what would a command set supporting directories 
look like. Then we'd have the implementation of those commands, 
documentation and training of users. I saw too jr's suggestion for 
system commands. I don't know...

I'll further hedge. Again due my tcl wrapper, I've not used the POV-Ray 
based IO all that much. You and others, understand SDL IO better than me.

Aside:
My few, true animations I've done with my wrapper so I can do other 
frame to frame work in tcl (as jr suggested useful) and more so to 
see/work with the "as calculated" per-frame scene files while 
debugging/developing. Being able to get an after SDL(tcl) 'runs' scene 
representation is helpful.

My pure POV-Ray animation use has been: Creating a few frames where 
early images are used in a final one; Tickets and promo stuff for an 
arts program; A large puzzle piece image for a town treasure/scavenger 
hunt where the 'animation' created the puzzle piece images which were 
printed on smaller photo sized paper edge to edge. POV-Ray and its 
animation capability is very useful for such projects.

Bill P.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2089 days 3 hours and 17 minutes ago]

Fri, 31 Jul 2020 23:20:01 GMT

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

> ran into a problem with some code I was sent.
>
> ==== [Parsing...] ==========================================================
> #include "spheresweep.inc" //version 1.2
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Possible Parse Error:
> Cannot find file 'Wrapper.inc', even after trying to append file type extension.
> File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
> Parse Error:
> Cannot open include file Wrapper.inc.
> Fatal error in parser: Cannot parse input.
> Render failed

That's a _weird_ error, especially since line 20 of shapes.inc is
#include "shapes_old.inc"

And there's no reference to 'Wrapper.inc' in either file.

Maybe if you have a reference to that, just comment it out?

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2089 days 4 hours and 7 minutes ago]

Fri, 31 Jul 2020 22:30:02 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached an updated tarball.
> ...

ran into a problem with some code I was sent.

==== [Parsing...] ==========================================================
#include "spheresweep.inc" //version 1.2
File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
Possible Parse Error:
Cannot find file 'Wrapper.inc', even after trying to append file type extension.
File '/home/jr/POVr/share/povray-3.8/include/shapes.inc' line 20:
Parse Error:
Cannot open include file Wrapper.inc.
Fatal error in parser: Cannot parse input.
Render failed

regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2089 days 8 hours and 42 minutes ago]

Fri, 31 Jul 2020 17:55:00 GMT

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 31/07/2020 Ã  16:40, jr a Ã©critÂ :
> > ... but reading the above made me realise that a modified '#fopen' which
> > supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
> > "everything" anyway.  then we could write, eg:
> >
> > #fopen FP "| program" rdwr
> >
> > to communicate with 'program', making creating a directory, all sorts of stuff,
> > easy and convenient.  for instance write some calculated parameters to 'program'
> > and read back new, derived values.
>
> "Danger Will Robinson"
>
> This could lead to some system corruption... A reason that there is
> already io-restrictions: to protect the innocent.

:-)  true.  otoh, the imagined '|program' form of '#fopen' could be made subject
to the same '[Shellout Security]' setting as the pre/post commands.

> You already have "shell-out" capability, with pre & post, scene & frame
> level, so grouping actions should be doable to have all you need.

also true, I guess, that those commands can be used to do "everything".  still,
there are differences.  for instance, now, if I need to pass multiple/many
calculated values to 'program', I have to write a temporary file to be processed
by 'program', and then read the results on the next frame.  a modified '#fopen'
would allow a different programming style, and would in the example obviate the
need for temporary file(s) and animation control.

regards, jr.

[Le Forgeron] Re: An updated povr tarball for Unix/Linux. f6b1... [2089 days 9 hours and 42 minutes ago]

Fri, 31 Jul 2020 16:55:21 GMT

Le 31/07/2020 Ã  16:40, jr a Ã©critÂ :
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> ...
>> Is it possible, and is there a security issue related to providing a means to
>> create a subdirectory in a write-permitted directory?
>>
>> #write creates a file.  Can we create a directory by a similar means?
>> Just something to think about.
> 
> have been thinking about (wishing for) for a 'system()' type function for a long
> time.  but reading the above made me realise that a modified '#fopen' which
> supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
> "everything" anyway.  then we could write, eg:
> 
> #fopen FP "| program" rdwr
> 
> to communicate with 'program', making creating a directory, all sorts of stuff,
> easy and convenient.  for instance write some calculated parameters to 'program'
> and read back new, derived values.
> 
>


"Danger Will Robinson"

This could lead to some system corruption... A reason that there is
already io-restrictions: to protect the innocent.


You already have "shell-out" capability, with pre & post, scene & frame
level, so grouping actions should be doable to have all you need.

http://wiki.povray.org/content/Reference:Shell_Command_Options

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2089 days 11 hours and 52 minutes ago]

Fri, 31 Jul 2020 14:45:00 GMT

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> Is it possible, and is there a security issue related to providing a means to
> create a subdirectory in a write-permitted directory?
>
> #write creates a file.  Can we create a directory by a similar means?
> Just something to think about.

have been thinking about (wishing for) for a 'system()' type function for a long
time.  but reading the above made me realise that a modified '#fopen' which
supports command pipelines, aided by a new OPEN_TYPE for r/w access could do
"everything" anyway.  then we could write, eg:

#fopen FP "| program" rdwr

to communicate with 'program', making creating a directory, all sorts of stuff,
easy and convenient.  for instance write some calculated parameters to 'program'
and read back new, derived values.

regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2089 days 18 hours and 12 minutes ago]

Fri, 31 Jul 2020 08:25:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/29/20 2:16 PM, jr wrote:
>...
> > I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
> > prefer to go back to the first version you posted.
>
> Could you be more specific?
>
> Povr breaks compatibility with as little as possible - but still quite a
> lot. My aim is to keep behavior near v3.8, but there is certainly more
> compatibility breakage to come. Is it more than wanting to continue to
> use lower case and/or includes which already have lower case?

no, for me it's just[*] the lower/uppercase stuff.  basically, each of my old
scenes I tried, failed.  I thought about modifying scene code, but since they
work I'll find it easier not to use (the new version of) 'povr'.

[*] at present.

> Are there actual conflicts/problems with the approach; or examples where
> it's very inconvenient?

just inconvenient.  eg, to "fix" the scene I used when I ran into the X11
animation issue, would be a lot of work, made worse by the fact that I got that
scene from the web, ie it's not even my code.

> The functionality is still hacked in - because I'm trying it too. :-)
> But, thus far, I'm liking the behavior.

cannot say the same.  guess I'm "allergic" to uppercase.  :-)

(could this behaviour be enabled/disabled via a 'povray.conf' setting instead?)

> ...
> > regarding that, I did a
> > 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> > call (including surrounding conditional) the only thing that would need to be
> > added to allow the _f9bc4ef7 version to function safely wrt X11?
> >
>
> As safely as the newer release, yes.

thanks, I'll try that then, sometime this weekend.

regards, jr.

[Bald Eagle] Re: An updated povr tarball for Unix/Linux. f6b1... [2090 days 1 hour and 52 minutes ago]

Fri, 31 Jul 2020 00:45:00 GMT

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

> Just back from a few days at real life. Back at povr for real tomorrow -
> or the day after. Ahead of me getting back...

Is it possible, and is there a security issue related to providing a means to
create a subdirectory in a write-permitted directory?

#write creates a file.  Can we create a directory by a similar means?
Just something to think about.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2090 days 3 hours and 6 minutes ago]

Thu, 30 Jul 2020 23:31:19 GMT

On 7/29/20 2:16 PM, jr wrote:

Hi,
Just back from a few days at real life. Back at povr for real tomorrow - 
or the day after. Ahead of me getting back...

> 
> I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
> prefer to go back to the first version you posted.  

Could you be more specific?

Povr breaks compatibility with as little as possible - but still quite a 
lot. My aim is to keep behavior near v3.8, but there is certainly more 
compatibility breakage to come. Is it more than wanting to continue to 
use lower case and/or includes which already have lower case?

Are there actual conflicts/problems with the approach; or examples where 
it's very inconvenient?

The functionality is still hacked in - because I'm trying it too. :-) 
But, thus far, I'm liking the behavior. In fact, I recently fixed a miss 
with command line declares letting lower case declare IDs still happen. 
That said, I've not run much old stuff with it as yet. Plus, suppose I 
wasn't in the habit of using lower case locals/declares to begin with.

Our SDL usage is different. I've not much jumped on the newer array, 
dictionary stuff, for example, mostly because it came well after my tcl 
wrapper - which already had that functionality.

regarding that, I did a
> 'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
> call (including surrounding conditional) the only thing that would need to be
> added to allow the _f9bc4ef7 version to function safely wrt X11?
> 

As safely as the newer release, yes.

There are other fixes and improvements relative to the prior release 
you'll be missing in using the first, but stuff should work except where 
there was already incompatible change - ie fog, inbuilt functions,...

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2091 days 8 hours and 17 minutes ago]

Wed, 29 Jul 2020 18:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Sure. You can continue to use any names you want for function and macro
> parameters. The _<lower> is the suggestion because it won't collide with
> future SDL keywords where some other lower case string might eventually
> - though probably not a_ :-).

I find I'm not .. getting on with the forced uppercase stuff (sorry), and would
prefer to go back to the first version you posted.  regarding that, I did a
'diff' on the respective 'vfe/unix/unixconsole.cpp' files, is the 'XInitThreads'
call (including surrounding conditional) the only thing that would need to be
added to allow the _f9bc4ef7 version to function safely wrt X11?

regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2099 days 10 hours and 47 minutes ago]

Tue, 21 Jul 2020 15:50:00 GMT

hi,

"jr" <cre### [at] gmailcom> wrote:
> ...
> right, and now we're getting to the bit where it gets .. strange.  :-)

ignore.  the problem was the symlinks in /usr/include not pointing to the
correct headers.  :-(  re-built 'povray2' and all three test scenes ok.


regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2099 days 12 hours and 2 minutes ago]

Tue, 21 Jul 2020 14:35:08 GMT

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 7/20/20 8:54 AM, jr wrote:
> > > ...
> > ... Hmm, wonder, if you've got multiple libraries and no symlink
> > to a version-less name like libpng.so.1 I'm unsure how one library would
> > be picked over another? Do you have the common sym link name given you
> > have two libpngs?
>
> bingo.  yes, the "version-less" names ('libpng.{la,so}') were pointing to the
> old(est) version; guess must have happened when I re-compiled/re-installed
> 1.6.37.  cheers.

right, and now we're getting to the bit where it gets .. strange.  :-)

built the new version of 'povray2', checked libpng link - ok, and 'make check'
ran fine, so installed.  went back into the scenes directory, and all three
scenes now fail with:
  ...
  Trace Time:       0 hours  0 minutes  0 seconds (0.354 seconds)
              using 4 thread(s) with 1.388 CPU-seconds total
Cannot allocate PNG data structures
Cannot allocate PNG data structures
Render failed

:-)  everything works as normal until it needs to write the disk file.

unfortunately cannot try those scenes with alpha.10064268, but checked that, and
other programs linking to 'libpng16', still work.  and 'povray2' output to, say,
jpeg, is ok.

'make check' succeeded because it doesn't actually try to write to disk?


regards, jr.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2099 days 15 hours and 32 minutes ago]

Tue, 21 Jul 2020 11:05:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/20/20 8:54 AM, jr wrote:
> > ...
> > one thing I noticed, 'povr' links against an older version of libpng, unlike the
> > "stock" POV-Ray.
> > ...

> ... Hmm, wonder, if you've got multiple libraries and no symlink
> to a version-less name like libpng.so.1 I'm unsure how one library would
> be picked over another? Do you have the common sym link name given you
> have two libpngs?

bingo.  yes, the "version-less" names ('libpng.{la,so}') were pointing to the
old(est) version; guess must have happened when I re-compiled/re-installed
1.6.37.  cheers.


regards, jr.

[William F Pokorny] Re: An updated povr tarball for Unix/Linux. f6b1... [2100 days 1 hour and 44 minutes ago]

Tue, 21 Jul 2020 00:52:57 GMT

On 7/20/20 8:54 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Please find attached an updated tarball.
> 
> thanks.  compiles.  will properly make + install sometime later this week.
> 
> one thing I noticed, 'povr' links against an older version of libpng, unlike the
> "stock" POV-Ray.
> 
> jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
>      ...
>      libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
>      ...
> jr@swift:14:~$ ldd POVr/bin/povray2
>      ...
>      libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
>      ...
> jr@swift:15:~$
> 
> the updated version too links to 1.2.50, when 1.6.37 is available.

Interesting find. :-) Unsure why you see a difference in library used.

It's my understanding when there are multiple versions of a library in 
place on a system there is usually a sym link established from a generic 
name to the 'official' one for the particular linux distribution. It 
would be normal then for the official distribution version to be picked 
up first. This is not necessarily the newest (or oldest) one if you have 
multiple development library versions on a system(1).

(1) - Not all that common, but certainly happens. I have only one libpng 
version on my Ubuntu 18.04 system.

There are certainly ways to override which library gets picked up 
explicitly. Hmm, wonder, if you've got multiple libraries and no symlink 
to a version-less name like libpng.so.1 I'm unsure how one library would 
be picked over another? Do you have the common sym link name given you 
have two libpngs?

> 
>> Attempting no lower case #declare, #local identifier idea. Hope is
>> user's function and macro arguments made _<lower case> form will be
>> immune to name collisions.
> 
> (crestfallen..)  hope 'a_' will be as acceptable as '_a'.
> 

Sure. You can continue to use any names you want for function and macro 
parameters. The _<lower> is the suggestion because it won't collide with 
future SDL keywords where some other lower case string might eventually 
- though probably not a_ :-).

Bill P.

[jr] Re: An updated povr tarball for Unix/Linux. f6b1... [2100 days 13 hours and 37 minutes ago]

Mon, 20 Jul 2020 13:00:08 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached an updated tarball.

thanks.  compiles.  will properly make + install sometime later this week.

one thing I noticed, 'povr' links against an older version of libpng, unlike the
"stock" POV-Ray.

jr@swift:13:~$ ldd /usr/local/bin/povray-3.8.0-alpha.10064268
    ...
    libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6cc19c5000)
    ...
jr@swift:14:~$ ldd POVr/bin/povray2
    ...
    libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fb50195f000)
    ...
jr@swift:15:~$

the updated version too links to 1.2.50, when 1.6.37 is available.

> Attempting no lower case #declare, #local identifier idea. Hope is
> user's function and macro arguments made _<lower case> form will be
> immune to name collisions.

(crestfallen..)  hope 'a_' will be as acceptable as '_a'.

> ...
> I've not seen an x11 display issue in the week since adding the
> XInitThreads() call - thanks jr. Thinking of making x11 the default as
> it's windowing behavior is more consistent with my Ubuntu environment.

+1.  :-)


regards, jr.

[William F Pokorny] An updated povr tarball for Unix/Linux. f6b1c13e [2100 days 16 hours and 37 minutes ago]

Mon, 20 Jul 2020 10:00:17 GMT

Please find attached an updated tarball.

Attempting no lower case #declare, #local identifier idea. Hope is 
user's function and macro arguments made _<lower case> form will be 
immune to name collisions.

With a thought toward eventual real time modeling, continuous real time 
rendering enabled as it has been in window's versions since v37. Added a 
rtr_kla.pov sample scene for the feature.

The rtr_kla.pov scene implements an alternative to the persistent 
keyword marking idea of uberpov. While the continuous / real time 
rendering only supports multiple camera positions today, multiple frames 
can be rendered with one scene parse where more than the camera changes.

The idea is to create multiple fixed sets in which changes are made and 
where a camera is appropriately placed in each. Mentally one must, of 
course, still keep track of what is persistent and what is not, but we'd 
not need a new keyword and the code infrastructure behind it - supposing 
eventual frame capture capability. Simpler, perhaps, to look at the 
sample scene to get the idea.

Corrections to the DOINGMAKECHECK=YES build implementation - thanks jr.

I've not seen an x11 display issue in the week since adding the 
XInitThreads() call - thanks jr. Thinking of making x11 the default as 
it's windowing behavior is more consistent with my Ubuntu environment.

Added an inbuilt f_toupie() function supporting 1-15 as integer 
exponents where f_toupie() usually uses 3. Provides for a range of 
shapes lemon like, torus like (exactly the torus at 2), toupie like and 
button-ish shapes.

Bill P.

[jr] Re: A povr tarball for Unix/Linux. [2108 days 13 hours and 27 minutes ago]

Sun, 12 Jul 2020 13:10:09 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> What I'm testing is what the nice, verbose error message from X
> suggested - XInitThreads. This seems to add lock / unlocks around all
> the x11 interactions. Thus far, it's working(1).
> (1) - The other x11 issues routinely seen OK too - so far.

that man page merits close reading.  it only speaks about 'Xlib', the "client
library", not (the underlying) X (server).  another pertinent man page, re the
event/interrupt issues snipped from below, is 'XIfEvent(3)'.  my understanding
(from somewhat dim, 20+ years old memory) is that whenever the window "object"
is accessed, you'll need some kind of mutex/XLockDisplay guard arrangement,
still.

another "rant" re "nice, verbose error message".  a few days ago, in an email,
needed to ask what the person (also an Ubuntu user, as it happens) got in reply
when executing "$ which badname", since "badname" did not seem to work.  answer:
"nothing (an empty line)".  the default behaviour for 'which' is to print (to
stderr) a message like "which: no badname in ($PATH)".  what I do not understand
is why the Ubuntu maintainers expend "man-hours"/time + effort on making s/ware
_less_ informative, and therefore less valuable, to the user.  (it sort of
boggles the mind, and that's before the "conspiracy" paranoia kicks in!  :-))

> ...
> Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a
> continuous loop(2) while accepting scene updating input. Re-reading and
> rendering a scene file as edits/updates are made. I think it possible to
> do limited modeling (spline editing say) without jumping up to Blender,
> Moray or whatever tool to do it.

a "hacked" Tclsh?!  ;-)  like the idea though, to be able to interactively build
up scenes would be way cool.

regards, jr.

[William F Pokorny] Re: A povr tarball for Unix/Linux. [2108 days 16 hours and 14 minutes ago]

Sun, 12 Jul 2020 10:23:37 GMT

On 7/11/20 11:04 AM, jr wrote:
...
>> I've not done any animations with the x11 display. I'll try it
>> myself later today. I'd make a moderate bet from your output it's again
>> the architectural problem of x11/sdl* not being at the top thread-wise,
>> so to speak.
> 
> thanks.  wish I knew/understood more about the code, 'disp_x11.*' etc.  naively,
> after the initialisation, just bracketing the worker thread's call to update the
> window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
> companion should do, no?
> 

:-) I suspect you know more than me. I'm no expert with X11, having only 
surfaced hacked now and again on code using X11. At a high level, if we 
have all the locking / unlocking in place to prevent thread safety 
issues while asking x11 to do stuff and visa versa, things would work.
;-)

What I'm testing is what the nice, verbose error message from X 
suggested - XInitThreads. This seems to add lock / unlocks around all 
the x11 interactions. Thus far, it's working(1).

(1) - The other x11 issues routinely seen OK too - so far.

I was able to duplicate your animation / X11 fails easily - thanks 
(without the sigh this time :-)). Start up an animation and then create 
many interrupts by moving the window hitting keys and such and somewhere 
in the first 20 frames - almost always - boom! Having something which 
fails reliably is very useful. I wasn't able to get there with the prior 
SDL1.2 github issues.

I'll run with the x11 display for a few days and we'll see if the 
XInitThreads() fix holds up.

In reading about it, it looks like it's not the efficient approach and 
likely there is additional exposure to hangs where an interrupt 
generating a lock happens elsewhere during a lock introduced by using 
XInitThreads(). The latter particular locks perhaps not strictly necessary.

The underlying issue tangled here, given our current code architecture, 
is the interrupt handing happening in ways that cause a deadlock of 
locks and hence occasional hangs. For users not generating large numbers 
of interface interrupts, I believe such hangs are rare.

Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a 
continuous loop(2) while accepting scene updating input. Re-reading and 
rendering a scene file as edits/updates are made. I think it possible to 
do limited modeling (spline editing say) without jumping up to Blender, 
Moray or whatever tool to do it.

(2) - Similar in behavior to animation today, but where modeling not 
animation is the aim. No image output, just continuous re-rendering of a 
changing scene to the display. Yes, ugly, partial hacks of this can be 
achieved today.

Bill P.

[jr] Re: A povr tarball for Unix/Linux. [2109 days 11 hours and 32 minutes ago]

Sat, 11 Jul 2020 15:05:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/11/20 5:31 AM, jr wrote:
> > have still not seen any "hangs", but managed to get an error; ...
>
> Thanks.

(I think I might have heard you <sigh>.  :-))

> I've not done any animations with the x11 display. I'll try it
> myself later today. I'd make a moderate bet from your output it's again
> the architectural problem of x11/sdl* not being at the top thread-wise,
> so to speak.

thanks.  wish I knew/understood more about the code, 'disp_x11.*' etc.  naively,
after the initialisation, just bracketing the worker thread's call to update the
window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
companion should do, no?

regards, jr.

[William F Pokorny] Re: A povr tarball for Unix/Linux. [2109 days 12 hours and 11 minutes ago]

Sat, 11 Jul 2020 14:26:13 GMT

On 7/11/20 5:31 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> In my povr/POV-Ray use all three display options still have issues with
>> x11 being the worst behaving. The x11 and SDL1.2 options suffer from
>> occasional hangs requiring a kill command to stop with x11 being worse.
> 
> have still not seen any "hangs", but managed to get an error; when beginning
> render of 2nd frame in animation.
> 
> povr +L/usr/local/share/povray-3.8/include +a0.1 +w960 +h720 \
>          +o/tmp/render/frm_ +iTorusKnotMinimal35.pov +kc +kfi0 +kff359
> 
> ....
> X error: BadLength (poly request too large or internal Xlib length error)
> .... [message repeats another eight times]
> [xcb] Unknown sequence number while processing queue
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been
> called
> [xcb] Aborting, sorry about that.
> povray2: xcb_io.c:259: poll_for_event: Assertion
> `!xcb_xlib_threads_sequence_lost' failed.
> /home/jr/bin/povr: line 14: 845235 Aborted    ${INSTALLDIR}/bin/povray2 -y x11
> $@
> 
> 
> regards, jr.
> 

Thanks. I've not done any animations with the x11 display. I'll try it 
myself later today. I'd make a moderate bet from your output it's again 
the architectural problem of x11/sdl* not being at the top thread-wise, 
so to speak.

Bill P.

[jr] Re: A povr tarball for Unix/Linux. [2109 days 17 hours and 2 minutes ago]

Sat, 11 Jul 2020 09:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> In my povr/POV-Ray use all three display options still have issues with
> x11 being the worst behaving. The x11 and SDL1.2 options suffer from
> occasional hangs requiring a kill command to stop with x11 being worse.

have still not seen any "hangs", but managed to get an error; when beginning
render of 2nd frame in animation.

povr +L/usr/local/share/povray-3.8/include +a0.1 +w960 +h720 \
        +o/tmp/render/frm_ +iTorusKnotMinimal35.pov +kc +kfi0 +kff359

....
X error: BadLength (poly request too large or internal Xlib length error)
.... [message repeats another eight times]
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been
called
[xcb] Aborting, sorry about that.
povray2: xcb_io.c:259: poll_for_event: Assertion
`!xcb_xlib_threads_sequence_lost' failed.
/home/jr/bin/povr: line 14: 845235 Aborted    ${INSTALLDIR}/bin/povray2 -y x11
$@

regards, jr.

[jr] Re: A povr tarball for Unix/Linux. [2110 days 7 hours and 17 minutes ago]

Fri, 10 Jul 2020 19:20:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/10/20 11:12 AM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> >> ...
> >> I'll play some more in the week, then post a list of .. issues.
> > ...
> Thanks! The first and likely the second issue(2) are the same problem.
> ...
> I believe the issue now fixed in my code.

looking forward to your posting an updated version.

> (1) - Related. I am taking a run at no longer installing .conf and ini
> defaults in a user's HOME directory. Doing this makes it hard to run
> several POV-Ray versions side by side - though I have hacks to do it.

agree that a user 'povray.conf' is not needed/useful.

feel different about the 'povray.ini', find it convenient to have a set of
defaults, for that login, which I can override on a case-by-case basis.  (could
you not install a 'povr.ini' in '~/.povray/3.8/'?  would get round the naming
issue)

> (2) - It might also be this second case is some actual incompatibility.
> I've made changes so more often the code will kick out the actual
> offending identifiers to make things easier to debug. On removal of old
> keywords, for example the errors should complain about the specific
> keyword. It's obviously still not reporting the identifier in your case.

I'll be happy to try that scene again, after installing the update.

> ...
> (*) - It's a hack at the moment, but I do have a povrTextDocumentation
> directory in the root compilation directoy which includes primarily
> areas of povr different than POV-Ray. If something exists there, it
> behaves differently in some way from the official POV-Ray. The
> exceptions to this rule in the inbuilt function changes are all
> documented in functions.inc and the density file stuff is on the wiki.

ok.  I had hoped for something included in the tarball.

and another "rant" :-), this time regarding the install locations.

what is wrong with '/usr/local/doc/'?  what is the rationale for
'/usr/local/share/doc/' and '/usr/local/share/man/'?  it cannot be the "shared"
aspect, because then, logically, other shared directories would belong there
too, eg '/usr/local/share/bin/'!  plain weird.  (and yes, I know it's an Ubuntu
thing, not your decision, per se)

regards, jr.

[William F Pokorny] Re: A povr tarball for Unix/Linux. [2110 days 8 hours and 21 minutes ago]

Fri, 10 Jul 2020 18:16:39 GMT

On 7/10/20 11:12 AM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> ...
>> I'll play some more in the week, then post a list of .. issues.
> 
> turns out that, so far, there are only two things on that list.  :-)
> 
> one is that 'povr' displays "povray: I/O restrictions are disabled".  confused.
> the 'povray.conf' file contains (edited):
> 
...
> 
> the second problem is a "third party" scene which fails:
> 
> ==== [Parsing...] ==========================================================
> FILE FOUND - Including ../...../L_01_04.inc
> File '/home/jr/POVr/share/povray-3.8/include/transforms.inc' line 92:
> Parse Error:
> Cannot pass uninitialized identifier to non-optional LValue.
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> that scene works fine with 10064268.alpha.
> 
> have not, so far, found the time to re-read the various newsgroup posts wrt
> 'povr' specific features and changes[*], so will probably use it just as an
> alternative to the 10064268.alpha.
> 
> [*] maybe you can put all those together, in some text file.
> 

Thanks! The first and likely the second issue(2) are the same problem.

There were updates to the code so that "make check" less often fails or 
is fooled by a previous install on the system doing the compile. Say an 
existing 'system level' functions.inc, a user setting of POVINI or 
whatever. Those changes required the introduction of a new internal only 
environment variable which when set (I think) turns off all the normal, 
nearly fanatical internal attempts to find existing .conf, .ini and .inc 
files(1) with which to run.

I screwed up the setting of the variable in the Makfile - and then 
covered up that mistake with another in the code hiding the fact I'd 
broken the normal setting of paths given I usually run with an uncommon 
POVINI setting. I believe the issue now fixed in my code.

(1) - Related. I am taking a run at no longer installing .conf and ini 
defaults in a user's HOME directory. Doing this makes it hard to run 
several POV-Ray versions side by side - though I have hacks to do it.

(2) - It might also be this second case is some actual incompatibility. 
I've made changes so more often the code will kick out the actual 
offending identifiers to make things easier to debug. On removal of old 
keywords, for example the errors should complain about the specific 
keyword. It's obviously still not reporting the identifier in your case.

Aside: Some of the bad command line flag / ini setting errors are now 
being reported too where they've long not been on unix platforms. Jerome 
added a workaround years back to kick out the command line text on 
errors, but that's less helpful than getting the more specific error text.

(*) - It's a hack at the moment, but I do have a povrTextDocumentation 
directory in the root compilation directoy which includes primarily 
areas of povr different than POV-Ray. If something exists there, it 
behaves differently in some way from the official POV-Ray. The 
exceptions to this rule in the inbuilt function changes are all 
documented in functions.inc and the density file stuff is on the wiki.

Bill P.

[jr] Re: A povr tarball for Unix/Linux. [2110 days 11 hours and 22 minutes ago]

Fri, 10 Jul 2020 15:15:01 GMT

"jr" <cre### [at] gmailcom> wrote:
> ...
> I'll play some more in the week, then post a list of .. issues.

turns out that, so far, there are only two things on that list.  :-)

one is that 'povr' displays "povray: I/O restrictions are disabled".  confused.
the 'povray.conf' file contains (edited):

[File I/O Security]
;none       ; all read and write operations on files are allowed.
;read-only  ; uses the "read+write" directories for writing (see below).
restricted  ; uses _only_ "read" and "read+write" directories for file I/O.

; [Shellout Security] determines whether POV-Ray will be allowed to call
; scripts (e.g. Post_Frame_Command) as specified in the documentation.
; Specify one of the 2 following values:
; - "allowed" means that shellout will work as specified in the documentation.
; - "forbidden" means that shellout will be disabled.
[Shellout Security]
;allowed
forbidden

have not yet tested whether it's just the displayed info.

the second problem is a "third party" scene which fails:

==== [Parsing...] ==========================================================
FILE FOUND - Including ../...../L_01_04.inc
File '/home/jr/POVr/share/povray-3.8/include/transforms.inc' line 92:
Parse Error:
Cannot pass uninitialized identifier to non-optional LValue.
Fatal error in parser: Cannot parse input.
Render failed

that scene works fine with 10064268.alpha.

have not, so far, found the time to re-read the various newsgroup posts wrt
'povr' specific features and changes[*], so will probably use it just as an
alternative to the 10064268.alpha.

[*] maybe you can put all those together, in some text file.

regards, jr.

[jr] Re: A povr tarball for Unix/Linux. [2115 days 11 hours and 22 minutes ago]

Sun, 5 Jul 2020 15:15:01 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 7/4/20 12:05 PM, jr wrote:
> > found a 'xpovicon.xpm' in the 3.5c source, copied that, and both the make and
> > make check went through.  ...
>
> Thanks much!

a real pleasure, actually.  (see below)

> ...
> Aside: In the whither thread you gently tossed an arrow at the Simple
> DirectMedia Layer use. ...
> My understanding is that SDL1.2 was chosen for v3.7 because of problems
> with x11 at the time - which perhaps are not all that different from
> what we still see with x11 today.

that, I think needs .. re-stating.  :-)

I'm not a betting person, but would put good money on: if you were to create a
VM and installed either Slackware (of course!  :-)) or some BSD-derived Linux,
or Solaris, you'd find no "problems with x11"[*].  I think that rather than from
the X Windows system, problems will occur when using a Ubuntu.  (Mark
Shuttleworth tried too hard to become the "cock on the midden"  :-))  (although,
having said that, who knows, perhaps it goes back to Debian)

[*] that's not to say that the API isn't .. cumbersome, or perfect.  O'Reilly
published a really good set of references to X11R5 and X11R6.

> In my povr/POV-Ray use all three display options still have issues with
> x11 being the worst behaving. The x11 and SDL1.2 options suffer from
> occasional hangs requiring a kill command to stop with x11 being worse.
> Not seen the hangs in SDL2.0, but there is once in a while a had row of
> pixels usually in the upper left on scaling to fit a window. I recommend
> SDL2.0 use today if you have a choice.

well now, "povr -y x11 ..." works beautifully here.  :-)  the only difference I
see is that the x11 gives me window that starts with a transparent background,
while the (default) SDL2 window is black when empty.

and _I_ really like that the X functionality is making a comeback.

first impressions, have only run a handful of scenes for quick trying out that
it "just works".  fully installed ~4.2M -- nice!  it feels quite .. sprightly,
the difference to the 10064268.alpha seems to be ~5% faster parse and ~10%
faster render.

I'll play some more in the week, then post a list of .. issues.

regards, jr.

[William F Pokorny] Re: A povr tarball for Unix/Linux. [2115 days 14 hours and 46 minutes ago]

Sun, 5 Jul 2020 11:50:57 GMT

On 7/4/20 12:05 PM, jr wrote:
> 
> found a 'xpovicon.xpm' in the 3.5c source, copied that, and both the make and
> make check went through.
> 
> thanks.  will play with it, a little, over the coming days.
> 

Thanks much! In my testing I only needed the .xbm files. Must of only 
searched for xbgmap.xpm when deciding to lose both the *.xpm files...

---
Aside: In the whither thread you gently tossed an arrow at the Simple 
DirectMedia Layer use. I've done a little debug work around 1.2 hangs 
and povr/hgpovray have SDL2.0 and x11 support thanks to Jerome.

https://github.com/POV-Ray/povray/issues/118

https://github.com/POV-Ray/povray/issues/142

My understanding is that SDL1.2 was chosen for v3.7 because of problems 
with x11 at the time - which perhaps are not all that different from 
what we still see with x11 today.

In my povr/POV-Ray use all three display options still have issues with 
x11 being the worst behaving. The x11 and SDL1.2 options suffer from 
occasional hangs requiring a kill command to stop with x11 being worse. 
Not seen the hangs in SDL2.0, but there is once in a while a had row of 
pixels usually in the upper left on scaling to fit a window. I recommend 
SDL2.0 use today if you have a choice.

Others can speak to it better than me, but I believe some of the issues 
come to our code architecture being non-standard with respect to 
interface handling. It would be more normal to have x11/SDL - or 
whatever interface handler be the main loop from which everything else 
is spawned.

Bill P.

[jr] Re: A povr tarball for Unix/Linux. [2116 days 10 hours and 27 minutes ago]

Sat, 4 Jul 2020 16:10:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> A work in progress, but it's getting there. At this point I'm mostly
> interested in whether others can get through 'make check' OK given the
> necessary development libraries are installed local to your machine (see
> ./unix/README.md).

found a 'xpovicon.xpm' in the 3.5c source, copied that, and both the make and
make check went through.

thanks.  will play with it, a little, over the coming days.

regards, jr.

[jr] Re: A povr tarball for Unix/Linux. [2116 days 11 hours and 2 minutes ago]

Sat, 4 Jul 2020 15:35:00 GMT

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Please find attached my initial attempt at a Unix/Linux tarball for the
> povr branch of POV-Ray.

:-)

> It will unpack into a directory called povray2 due my own development
> naming. Supposing you unpack into /tmp/povray2 , it should be you can cd
> into that directory and do something like:
>
> ./configure COMPILED_BY="wfp" --prefix=/tmp/povr
> make
....
disp_x11.cpp:53:57: fatal error: xpovicon.xpm: No such file or directory

a quick 'find' confirmed that the icon's missing.


regards, jr.

[William F Pokorny] A povr tarball for Unix/Linux. [2116 days 12 hours ago]

Sat, 4 Jul 2020 14:37:30 GMT

Please find attached my initial attempt at a Unix/Linux tarball for the 
povr branch of POV-Ray.

It will unpack into a directory called povray2 due my own development 
naming. Supposing you unpack into /tmp/povray2 , it should be you can cd 
into that directory and do something like:

./configure COMPILED_BY="wfp" --prefix=/tmp/povr
make
make check

Optionally:
make install

The install size is 4-5MB. There is a script called povr in the root 
directory. After a little editing, it can be used to run the compile 'in 
place' or from an 'installed' compile result. Copy povr to your bin 
directory or otherwise get it into your $PATH. After which, unix help: 
povr --help

There are a couple of scenes in the scenes directory which should run 
with 'povr fog.pov', say, once you have the povr script set up. A 
reminder povr, often as not, breaks compatibility with existing POV-Ray 
scenes.

A work in progress, but it's getting there. At this point I'm mostly 
interested in whether others can get through 'make check' OK given the 
necessary development libraries are installed local to your machine (see 
./unix/README.md).

Bill P.

[Mr] Re: Interested in CMake support [2136 days 6 hours and 2 minutes ago]

Sun, 14 Jun 2020 20:35:00 GMT

Thomas Debe <"sert:delta"@gmx.de> wrote:
> s. <web.580c7dd8dc6ec2767a3e03fe0@news.povray.org>

Thank you  !!!!

[Thomas Debe] Interested in CMake support [2138 days 11 hours and 56 minutes ago]

Fri, 12 Jun 2020 14:40:55 GMT

s. <web.580c7dd8dc6ec2767a3e03fe0@news.povray.org>

[DigitalBox] Povray on NAS Synology [2491 days 10 hours and 2 minutes ago]

Tue, 25 Jun 2019 16:35:01 GMT

After a hard work, I finally manage to have povray compiled & running on a NAS
DS716+II.
Challenge completed ;)

As cross compiling scripts are not 100% automatic today, it currently requires
some manual editing of the configure script.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3452 days 12 hours and 37 minutes ago]

Sun, 6 Nov 2016 14:00:00 GMT

if use C++11:
[ 29%] Building CXX object
CMakeFiles/povanim.dir/source/core/support/octree.cpp.o
/home/leonid/workspace/programming/povanim_povray/povray/source/core/support/octree.cpp:110:55:
warning: missing terminating ' character
         #error 'int' is not 32 bit or does not use two's complement encoding;
try a different C99_COMPATIBLE_RADIOSITY setting in config.h

And:
/home/leonid/workspace/programming/povanim_povray/povray/source/base/image/hdr.cpp:
In function 'void pov_base::HDR::ReadOldLine(unsigned char*, int,
pov_base::IStream*)':
/home/leonid/workspace/programming/povanim_povray/povray/source/base/image/hdr.cpp:135:21:
warning: converting 'false' to pointer type 'const void*' [-Wconversion-null]
         if(*file == false)

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3453 days 11 hours and 47 minutes ago]

Sat, 5 Nov 2016 14:50:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 04.11.2016 um 20:26 schrieb LanuHum:
> > Why not add the name of the texture in texture.h to use options?
>
> Because it's entirely irrelevant for the render engine.
>
> > Your text:
> > struct Texture_Struct: public Pattern_Struct
> > {
> >      TextureBlendMapPtr Blend_Map;
> >      int References;
> >      TEXTURE * Next;
> >      string name; // Add your code !!!!!!!!!!!!!!!!
> >
> >
> > It will not affect the code, but it allows you to manipulate using povray as a
> > library...
>
> It will waste memory, adding 40(!) bytes of overhead per texture
> (Windows 64-bit binary; other platforms may vary) even if the name is
> unused.
>
> Even a C-style string (char*) would add 8 bytes of overhead (again
> Windows 64-bit binary).
>
> As I sad before, such a name is entirely irrelevant during rendering.
>
>
> Also, if the string is intended to reference textures by name, it would
> be pretty inefficient to store that information in the texture itself,
> as to find a texture you'd have to visit all of them and compare the
> string. It would be much faster to store the name->texture mappings in a
> separate data structure optimized for such purposes, e.g. a hash map or
> a search tree.
>
> And such a data structure wouldn't have to be part of the render engine
> anyway: It could easily be set up and managed by whatever program
> intends to feed the render engine with data.
>
> The reasons why you're running into so many complications is that you're
> trying to somehow shoehorn your Blender-to-POV-Ray bridge into the
> existing parser, rather than bypassing the parser entirely.

Thanks.
I will sort this out.

I want to keep the possibility of including files written by hand.
Blender does not allow me to establish. Example: the slope_map.
Probably, I will try to add a my GUI texture editor.
But it is a task that must be performed after.
:)

[clipka] Re: My idea: Developers need tips! Help me, plea... [3453 days 18 hours and 12 minutes ago]

Sat, 5 Nov 2016 08:25:36 GMT

Am 04.11.2016 um 20:26 schrieb LanuHum:
> Why not add the name of the texture in texture.h to use options?

Because it's entirely irrelevant for the render engine.

> Your text:
> struct Texture_Struct: public Pattern_Struct
> {
>      TextureBlendMapPtr Blend_Map;
>      int References;
>      TEXTURE * Next;
>      string name; // Add your code !!!!!!!!!!!!!!!!
> 
> 
> It will not affect the code, but it allows you to manipulate using povray as a
> library...

It will waste memory, adding 40(!) bytes of overhead per texture
(Windows 64-bit binary; other platforms may vary) even if the name is
unused.

Even a C-style string (char*) would add 8 bytes of overhead (again
Windows 64-bit binary).

As I sad before, such a name is entirely irrelevant during rendering.


Also, if the string is intended to reference textures by name, it would
be pretty inefficient to store that information in the texture itself,
as to find a texture you'd have to visit all of them and compare the
string. It would be much faster to store the name->texture mappings in a
separate data structure optimized for such purposes, e.g. a hash map or
a search tree.

And such a data structure wouldn't have to be part of the render engine
anyway: It could easily be set up and managed by whatever program
intends to feed the render engine with data.

The reasons why you're running into so many complications is that you're
trying to somehow shoehorn your Blender-to-POV-Ray bridge into the
existing parser, rather than bypassing the parser entirely.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3454 days 6 hours and 57 minutes ago]

Fri, 4 Nov 2016 19:40:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Why not add the name of the texture in texture.h to use options?
> Your text:
> struct Texture_Struct: public Pattern_Struct
> {
>      TextureBlendMapPtr Blend_Map;
>      int References;
>      TEXTURE * Next;
>      string name; // Add your code !!!!!!!!!!!!!!!!
>
>
> It will not affect the code, but it allows you to manipulate using povray as a
> library...

It can be applied to all objects: object, pigment, finish...ans so on...

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3454 days 7 hours and 7 minutes ago]

Fri, 4 Nov 2016 19:30:01 GMT

Why not add the name of the texture in texture.h to use options?
Your text:
struct Texture_Struct: public Pattern_Struct
{
     TextureBlendMapPtr Blend_Map;
     int References;
     TEXTURE * Next;
     string name; // Add your code !!!!!!!!!!!!!!!!


It will not affect the code, but it allows you to manipulate using povray as a
library...

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3454 days 7 hours and 22 minutes ago]

Fri, 4 Nov 2016 19:15:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 04.11.2016 um 14:54 schrieb LanuHum:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 04.11.2016 um 12:59 schrieb LanuHum:
> >>
> >>> At textures no name. How to initialize?
> >>
> >> I'm not sure what you mean.
> >>
> >> POV-Ray's render engine does not use any names -- neither for objects
> >> nor for textures. That's just a thing used in the parser to make life
> >> easier for users.
> >
> >
> > File Scene.pov:
> >
> > #declare Tex0 = texture {...}
> > #declare Tex1 = texture {...}
> > #declare Tex2 = texture {...}
> > #declare Tex3 = texture {...}
> >
> > #declare Foo = blender_object { "foo" }
>
> Well, wouldn't the Blender object named "foo" also include references to
> the textures as they are defined in Blender?

Yes. I load objects to the parser.
Or should I convey texture code. I want to pass only the geometry.

>
> If not, then you'll of course have to design the syntax of
> "blender_object" in such a manner that you can list the POV-Ray textures
> that the Blender object is supposed to use, maybe like so:
>
>     blender_object {
>       STRING
>       texture_list {
>         texture { Tex0 },
>         texture { Tex1 },
>         texture { Tex2 },
>         texture { Tex3 }
>       }
>     }

I'll break your head about it.

[clipka] Re: My idea: Developers need tips! Help me, plea... [3454 days 8 hours and 38 minutes ago]

Fri, 4 Nov 2016 17:59:09 GMT

Am 04.11.2016 um 14:54 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 04.11.2016 um 12:59 schrieb LanuHum:
>>
>>> At textures no name. How to initialize?
>>
>> I'm not sure what you mean.
>>
>> POV-Ray's render engine does not use any names -- neither for objects
>> nor for textures. That's just a thing used in the parser to make life
>> easier for users.
> 
> 
> File Scene.pov:
> 
> #declare Tex0 = texture {...}
> #declare Tex1 = texture {...}
> #declare Tex2 = texture {...}
> #declare Tex3 = texture {...}
> 
> #declare Foo = blender_object { "foo" }

Well, wouldn't the Blender object named "foo" also include references to
the textures as they are defined in Blender?

If not, then you'll of course have to design the syntax of
"blender_object" in such a manner that you can list the POV-Ray textures
that the Blender object is supposed to use, maybe like so:

    blender_object {
      STRING
      texture_list {
        texture { Tex0 },
        texture { Tex1 },
        texture { Tex2 },
        texture { Tex3 }
      }
    }

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3454 days 12 hours and 42 minutes ago]

Fri, 4 Nov 2016 13:55:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 04.11.2016 um 12:59 schrieb LanuHum:
>
> > At textures no name. How to initialize?
>
> I'm not sure what you mean.
>
> POV-Ray's render engine does not use any names -- neither for objects
> nor for textures. That's just a thing used in the parser to make life
> easier for users.


File Scene.pov:

#declare Tex0 = texture {...}
#declare Tex1 = texture {...}
#declare Tex2 = texture {...}
#declare Tex3 = texture {...}

#declare Foo = blender_object { "foo" }


1. Load mesh from Blender. I do not create BlenderMesh. I immediately create a
Povray Mesh2.

#include "core/shape/mesh.h"

Mesh* Object = new Mesh();

...........................

//Mesh uses four texture.

    for( i=0; i < 4; i++) Textures[i] = Create_Texture();
or
    for( i=0; i < 4; i++) Textures[i] = NULL;


   Object->Data = reinterpret_cast<MESH_DATA *>(POV_MALLOC...
   Object->Data->Normals   = Normals;
   Object->Data->Triangles = Triangles;
   Object->Data->Vertices  = Vertices;
   Object->Data->UVCoords  = UVCoords;

   Object->Textures  = Textures;  //  !!!!!!!!!

   Object->Data->Number_Of_Normals = number_of_normals;
   Object->Data->Number_Of_Triangles = number_of_triangles;
   Object->Data->Number_Of_Vertices = number_of_vertices;
   Object->Data->Number_Of_UVCoords  = number_of_uvcoords;
   Object->Number_Of_Textures = number_of_textures;

2. Parse Scene.pov

    char *s;
    ...
    CASE(BLENDER_OBJECT_TOKEN)
        Parse_Begin();
        s = Parse_C_String();
        Object = addBlenderObject(std::string(s));
        Object -> Textures[0] = Tex0  // How to implement this?
        Object -> Textures[1] = Tex1
        Object -> Textures[2] = Tex2
        Object -> Textures[3] = Tex3
        POV_FREE(s);
        Parse_End();
    END_CASE


???????? :)

[clipka] Re: My idea: Developers need tips! Help me, plea... [3454 days 13 hours and 47 minutes ago]

Fri, 4 Nov 2016 12:50:31 GMT

Am 04.11.2016 um 12:59 schrieb LanuHum:

> At textures no name. How to initialize?

I'm not sure what you mean.

POV-Ray's render engine does not use any names -- neither for objects
nor for textures. That's just a thing used in the parser to make life
easier for users.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3454 days 14 hours and 32 minutes ago]

Fri, 4 Nov 2016 12:05:00 GMT

Now the scene I add Povray mesh2


                PyObject* textureList = PyList_GetItem(blenderObject,5);
                number_of_textures = PyObject_Size(textureList);
                if (number_of_textures>0)
                {
                    Textures = reinterpret_cast<TEXTURE
**>(POV_MALLOC(number_of_textures*sizeof(TEXTURE *), "triangle mesh data"));
                    for(i=0; i<number_of_textures; i++)
                    {
                        PyObject* pyName = PyList_GetItem(textureList,i);
                        PyObject* pyTexture = PyObject_Repr(pyName);
                        pyTexture = PyUnicode_AsEncodedString(pyTexture,
"ASCII","Error ~");
                        const char *cTexture = PyBytes_AS_STRING(pyTexture);
                        Textures[i] = Create_Texture();
                        Post_Textures(Textures[i]);
                    }
                }


At textures no name. How to initialize?

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3458 days 12 hours and 37 minutes ago]

Mon, 31 Oct 2016 14:00:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 30.10.2016 um 11:16 schrieb LanuHum:
>
> My personal recommendation would be to add another keyword, e.g.
> "blender_object", write completely separate code to parse that, and use
> a string rather than an identifier to specify the Blender-internal name:
>
>     #declare Foo = blender_object { "foo" }
>
> The code would be something like:
>
>     char *s;
>     ...
>     CASE(BLENDER_OBJECT_TOKEN)
>         Parse_Begin();
>         s = Parse_C_String();
>         Object = addBlenderObject(std::string(s));
>         POV_FREE(s);
>         Parse_End();
>     END_CASE
>
>


Thanks!

[clipka] Re: My idea: Developers need tips! Help me, plea... [3459 days 5 hours and 28 minutes ago]

Sun, 30 Oct 2016 21:09:36 GMT

Am 30.10.2016 um 11:16 schrieb LanuHum:
> "LanuHum" <Lan### [at] yandexru> wrote:
>> "LanuHum" <Lan### [at] yandexru> wrote:
>>
>>  6775:   CASE (OBJECT_TOKEN)
>>              Parse_Begin ();
>>              Object = Parse_Object ();
>>              if (!Object)
>>                  bool add = addBlenderObject(Token.Token_String);
>>              if (!add)
>>                  Expectation_Error ("object");
>>              Object = Parse_Object_Mods (reinterpret_cast<ObjectPtr>(Object));
>>              EXIT
>>          END_CASE

No, you probably do /not/ want to do it this way.

Parse_Object may fail not only if an IDENTIFIER_TOKEN (a valid but
undeclared identifier) is used; it may also fail on virtually any other
token, e.g. a string literal, numeric literal, operator, a reserved
keyword that does not normally start a primitive, or even a string variable.

In case of a string literal, you'll get the raw string without the
surrounding double quotes.
If you want that to be supported, for the sake of consistency you should
also allow arbitrary string expressions -- but those would /not/ give
you the string in Token.Token_String; instead, that would just give you
the first token of that string expresison (e.g. "concat(Foo,Bar)" would
give you "concat).

My personal recommendation would be to add another keyword, e.g.
"blender_object", write completely separate code to parse that, and use
a string rather than an identifier to specify the Blender-internal name:

    #declare Foo = blender_object { "foo" }

The code would be something like:

    char *s;
    ...
    CASE(BLENDER_OBJECT_TOKEN)
        Parse_Begin();
        s = Parse_C_String();
        Object = addBlenderObject(std::string(s));
        POV_FREE(s);
        Parse_End();
    END_CASE

> bool BlenderScene::addBlenderObject(std::string name){
>     BlenderObject *bobject = objects.find(name) -> second;
>     if (!bobject)
>         return false
>     switch (bobject -> type) {
>         case 2: {
>             Mesh *mesh = new Mesh();
>             // reinterpret Blender mesh data to Povray mesh data
>             // bla-bla-bla
>         }
>         case 1: { std::cout<<"Type: "<<"CSG"<<std::endl; break; } //del
>         default: { std::cout<<"Type: "<<"BLOB"<<std::endl; } //del
>     }
>     return true
> }

You /somehow/ want to pass the mesh/blob object out of this function.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3459 days 16 hours and 17 minutes ago]

Sun, 30 Oct 2016 10:20:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
>
>  6775:   CASE (OBJECT_TOKEN)
>              Parse_Begin ();
>              Object = Parse_Object ();
>              if (!Object)
>                  bool add = addBlenderObject(Token.Token_String);
>              if (!add)
>                  Expectation_Error ("object");
>              Object = Parse_Object_Mods (reinterpret_cast<ObjectPtr>(Object));
>              EXIT
>          END_CASE


bool BlenderScene::addBlenderObject(std::string name){
    BlenderObject *bobject = objects.find(name) -> second;
    if (!bobject)
        return false
    switch (bobject -> type) {
        case 2: {
            Mesh *mesh = new Mesh();
            // reinterpret Blender mesh data to Povray mesh data
            // bla-bla-bla
        }
        case 1: { std::cout<<"Type: "<<"CSG"<<std::endl; break; } //del
        default: { std::cout<<"Type: "<<"BLOB"<<std::endl; } //del
    }
    return true
}

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3459 days 17 hours and 7 minutes ago]

Sun, 30 Oct 2016 09:30:00 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > Thanks! I am trying to understand.
>
>
> I looked neither to! (I have not looked back!)
> Will it work?
>
> 6775:   CASE (OBJECT_TOKEN)
>             Parse_Begin ();
>             Object = Parse_Object ();
>             if (!Object)
>                 addBlenderObject(Token.Token_String);
>             Object = Parse_Object ();
>             if (!Object)
>                 Expectation_Error ("object");
>             Object = Parse_Object_Mods (reinterpret_cast<ObjectPtr>(Object));
>             EXIT
>         END_CASE

 6775:   CASE (OBJECT_TOKEN)
             Parse_Begin ();
             Object = Parse_Object ();
             if (!Object)
                 bool add = addBlenderObject(Token.Token_String);
             if (!add)
                 Expectation_Error ("object");
             Object = Parse_Object_Mods (reinterpret_cast<ObjectPtr>(Object));
             EXIT
         END_CASE

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3459 days 17 hours and 12 minutes ago]

Sun, 30 Oct 2016 09:25:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Thanks! I am trying to understand.


I looked neither to! (I have not looked back!)
Will it work?

6775:   CASE (OBJECT_TOKEN)
            Parse_Begin ();
            Object = Parse_Object ();
            if (!Object)
                addBlenderObject(Token.Token_String);
            Object = Parse_Object ();
            if (!Object)
                Expectation_Error ("object");
            Object = Parse_Object_Mods (reinterpret_cast<ObjectPtr>(Object));
            EXIT
        END_CASE

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3459 days 17 hours and 52 minutes ago]

Sun, 30 Oct 2016 08:45:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 30.10.2016 um 07:36 schrieb LanuHum:
>
> > Now we need to understand here:
> > povray-master/source/parser/parser.cpp:
> > 6704:       CASE (OBJECT_ID_TOKEN)
> >             Object = Copy_Object(reinterpret_cast<ObjectPtr>(Token.Data));
> >             EXIT
> >             END_CASE
> >
> > In .pov:
> > object{Human}
> >
> > But Human no declare:
> > File '/tmp/Scene.pov' line 17: Parse Error: Expected 'object', undeclared
> >  identifier 'Human' found instead
> > Fatal error in parser: Cannot parse input.
> > Render failed
> >
> > It needs to be fixed:
> > if (undeclared identifier){go to BlenderScene}
>
> Note that in the POV-Ray parser, the job of identifying the type of a
> variable is integrated into the tokenizer: The token type is only set to
> OBJECT_ID_TOKEN if the variable is defined as a geometric object
> (sphere, box, whatever).
>
> For undeclared identifiers, the tokenizer sets the token type to
> IDENTIFIER_TOKEN.

Thanks! I am trying to understand.

[clipka] Re: My idea: Developers need tips! Help me, plea... [3459 days 18 hours and 11 minutes ago]

Sun, 30 Oct 2016 08:26:34 GMT

Am 30.10.2016 um 07:36 schrieb LanuHum:

> Now we need to understand here:
> povray-master/source/parser/parser.cpp:
> 6704:       CASE (OBJECT_ID_TOKEN)
>             Object = Copy_Object(reinterpret_cast<ObjectPtr>(Token.Data));
>             EXIT
>             END_CASE
> 
> In .pov:
> object{Human}
> 
> But Human no declare:
> File '/tmp/Scene.pov' line 17: Parse Error: Expected 'object', undeclared
>  identifier 'Human' found instead
> Fatal error in parser: Cannot parse input.
> Render failed
> 
> It needs to be fixed:
> if (undeclared identifier){go to BlenderScene}

Note that in the POV-Ray parser, the job of identifying the type of a
variable is integrated into the tokenizer: The token type is only set to
OBJECT_ID_TOKEN if the variable is defined as a geometric object
(sphere, box, whatever).

For undeclared identifiers, the tokenizer sets the token type to
IDENTIFIER_TOKEN.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3459 days 19 hours and 57 minutes ago]

Sun, 30 Oct 2016 06:40:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:

> To be continued.
> :)

Now we need to understand here:
povray-master/source/parser/parser.cpp:
6704:       CASE (OBJECT_ID_TOKEN)
            Object = Copy_Object(reinterpret_cast<ObjectPtr>(Token.Data));
            EXIT
            END_CASE

In .pov:
object{Human}

But Human no declare:
File '/tmp/Scene.pov' line 17: Parse Error: Expected 'object', undeclared
 identifier 'Human' found instead
Fatal error in parser: Cannot parse input.
Render failed

It needs to be fixed:
if (undeclared identifier){go to BlenderScene}

:)

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3468 days 10 hours and 7 minutes ago]

Fri, 21 Oct 2016 16:30:00 GMT

Now I know how to create a mesh:

/********************************************************************************
*
*
*                                   BlenderMesh.h
*
*
*
********************************************************************************/
#ifndef BLENDERMESH_H
#define BLENDERMESH_H

#include <vector>
#include <string>
#include "Vector.h"

namespace povanim{

class BlenderMesh{
    public:
    std::vector<Vector3*>           vertex_vectors;  //Vector3 double
    std::vector<Vector3*>           normal_vectors;
    std::vector<Vector2*>           uv_vectors;
    std::vector<std::string>        texture_list;
    std::vector<Vector3UL*>         face_indices;  //Vector3 unsigned long
    std::vector<Vector3UL*>         face_textures;
    std::vector<Vector3UL*>         normal_indices;
    std::vector<Vector3UL*>         uv_indices;
                                    BlenderMesh();
                                    ~BlenderMesh();
    void                            addVertex(double x, double y, double z);
    void                            addNormal(double x, double y, double z);
    void                            addUV(double x, double y);
    void                            addTexture(std::string texture);
    void                            addFace(unsigned long x, unsigned long y,
unsigned long z);
    void                            addFaceTextures(unsigned long x, unsigned
long y, unsigned long z);
    void                            addNormalIndices(unsigned long x, unsigned
long y, unsigned long z);
    void                            addUVIndices(unsigned long x, unsigned long
y, unsigned long z);
};
}
#endif


To be continued.
:)

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3474 days 8 hours and 17 minutes ago]

Sat, 15 Oct 2016 18:20:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:

> A new attempt: the bootloader on a Cython.

It kills me. :) Sometime later :)


> clipka <ano### [at] anonymousorg> wrote:
>
> > That said, the thing you are looking for is the class `SceneData`
> > declared in `source/core/scene/scenedata.h`
>
> All right. I watched this file.
>
>         ~SceneData();
>
>         /// list of all shape objects
>         vector<ObjectPtr> objects;
>         /// list of all global light sources
>         vector<LightSource *> lightSources;
>         /**
>          *  Create new scene specific data.
>          */
>         SceneData(GenericFunctionContextFactory* fcf);
>
> A pointer to the object is absent, the light pointer is present.
> How to implement my.cpp?
>
> SceneData::SceneData(){};
>
> SceneData *scene = new SceneData();
> for (ulong i = 0; i < numberBlenderObjects; i++){
>     ObjectPtr *object = new ObjectPtr();
>     object = BlenderObjects[i];
>     scene -> objects.push_back(object);}

I want to do this:

#include <map>
#include "core/scene/object.h"
#include "core/shape/mesh.h"

using namespace pov;

class BlenderScene{

    public:
        .....
        std::map<string,ObjectBase*>  shapes;
        .....
}

BlenderScene *bscene = new BlenderScene()
for (ulong i = 0; i < numberBlenderObjects; i++){
    if (type==0){
       Mesh *pMesh = new Mesh();
       ...// Building povray mesh from blender
       bscene->shapes.insert( pair<string,Mesh>(name,pMesh) );
}}

Next in the povray_run...
SceneData *scene = new SceneData();
If in .pov string:
 #declare Cube = mesh2{load_from_bscene}:

scene -> objects.push_back(bscene->shapes.find(name));

If the static mesh: will not restart.
If mesh use bone or other modifiers which move vertices:
  ob=bscene->shapes.find(name);
  bscene->shapes.erase (ob);
  Mesh *pMesh = new Mesh();
  ...// Building povray mesh from blender
  bscene->shapes.insert( pair<string,Mesh>(name,pMesh) );


Control of objects in the bscene is performed to parse...

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3475 days 8 hours and 7 minutes ago]

Fri, 14 Oct 2016 18:30:00 GMT

Mesh: 3 145 728 tris
If I use the bootloader on a Python: Create an PyObject(Mesh) takes 28 seconds.
A new attempt: the bootloader on a Cython.
I have to get ready for an instance of the mesh.
I created a new repository:
https://github.com/Lanuhum/Povanim

I used your license, but FOX-TOOLKIT is licensed under GNU LESSER GENERAL PUBLIC
LICENSE Version 2.1.
I shoot? :)))


Now GUI looks like this:

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3485 days 5 hours and 57 minutes ago]

Tue, 4 Oct 2016 20:40:01 GMT

You can not give up on SDL.

Example scene.pov:

#version 3.7;

camera{...}

light_source{...}

#declare Home_tex = texture{...}

#declare Home = mesh { load_using_C++_library }

object { Home }


The code adds a new key: " load_using_C++_library "

Also add a new key code: "to_take_out_of_memory"

#declare Home = mesh { to_take_out_of_memory }

First frame:
#declare Home = mesh { load_using_C++_library }

Second frame:
#declare Home = mesh { to_take_out_of_memory } // if object static


for (uint frame = 1; frame < frame_end; frame++){
    string *filename = filenames[frame];
    parser::run(filename);
    render::run();
}

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3487 days 6 hours and 32 minutes ago]

Sun, 2 Oct 2016 20:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 02.10.2016 um 19:27 schrieb LanuHum:
> > clipka <ano### [at] anonymousorg> wrote:
> >
> >> That said, the thing you are looking for is the class `SceneData`
> >> declared in `source/core/scene/scenedata.h`
> >
> > All right. I watched this file.
> >
> >         ~SceneData();
> >
> >         /// list of all shape objects
> >         vector<ObjectPtr> objects;
> >         /// list of all global light sources
> >         vector<LightSource *> lightSources;
> >         /**
> >          *  Create new scene specific data.
> >          */
> >         SceneData(GenericFunctionContextFactory* fcf);
> >
> > A pointer to the object is absent,
>
> I don't know what you mean by that. We have the `vector<ObjectPtr>
> objects` there, nice and square.
>
>
> > How to implement my.cpp?
> >
> > SceneData::SceneData(){};
> >
> > SceneData *scene = new SceneData();
> > for (ulong i = 0; i < numberBlenderObjects; i++){
> >     ObjectPtr *object = new ObjectPtr();
> >     object = BlenderObjects[i];
> >     scene -> objects.push_back(object);}
>
> Uh... no, not exactly:
>
> ObjectPtr is not a class type; it's a /pointer/ to a class type
> (currently a plain C pointer, but might be made a `shared_ptr<>` some
> time in the future). Also, the type it points to is actually an abstract
> polymorphic base type, `ObjectBase`; the type you'll need to instantiate
> depends on the primitive type you want; for example:
>
>    Sphere *pSphere = new Sphere();
>    pSphere->Center = Vector3d(BlenderObjects[i].Center);
>    pSphere->Radius = BlenderObjects[i].Radius;
>    scene->objects.push_back (pSphere);
>
> or:
>
>    Box *pBox = new Box();
>    pBox->bounds[0] = Vector3d(BlenderObjects[i].BottomLeft);
>    pBox->bounds[1] = Vector3d(BlenderObjects[i].TopRight);
>    scene->objects.push_back (pBox);
>
> or:
>
>    Mesh *pMesh = new Mesh();
>    // ...
>    scene->objects.push_back (pMesh);
>
> Note that much of the sanity-checking and precomputing of various stuff
> is still implemented in the parser, rather than the primitive classes
> where it would belong.
>
> Also, in addition to the stuff the parser does while parsing the SDL
> file, there are some additional steps required between the parsing and
> the invocation of the render engine, such as propagating some
> information between parent and child objects, setting up a bounding
> hierarchy to speed up rendering, and other stuff like that.
>
> Don't say I didn't warn you...

:))))
Thank you.
My idea is only useful for animation. To speed up the data transfer very large.
Parents and children do not interest me.
Earlier you wrote me that well write:
sphere{}
sphere{}
sphere{}
than the cycle "for (i=0;i<3;i++)..."

I am most interested in triangles.
I will try to deal with the povray-master/source/core/shape/mesh.h

[clipka] Re: My idea: Developers need tips! Help me, plea... [3487 days 7 hours and 27 minutes ago]

Sun, 2 Oct 2016 19:10:43 GMT

Am 02.10.2016 um 19:27 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
> 
>> That said, the thing you are looking for is the class `SceneData`
>> declared in `source/core/scene/scenedata.h`
> 
> All right. I watched this file.
> 
>         ~SceneData();
> 
>         /// list of all shape objects
>         vector<ObjectPtr> objects;
>         /// list of all global light sources
>         vector<LightSource *> lightSources;
>         /**
>          *  Create new scene specific data.
>          */
>         SceneData(GenericFunctionContextFactory* fcf);
> 
> A pointer to the object is absent,

I don't know what you mean by that. We have the `vector<ObjectPtr>
objects` there, nice and square.

> How to implement my.cpp?
> 
> SceneData::SceneData(){};
> 
> SceneData *scene = new SceneData();
> for (ulong i = 0; i < numberBlenderObjects; i++){
>     ObjectPtr *object = new ObjectPtr();
>     object = BlenderObjects[i];
>     scene -> objects.push_back(object);}

Uh... no, not exactly:

ObjectPtr is not a class type; it's a /pointer/ to a class type
(currently a plain C pointer, but might be made a `shared_ptr<>` some
time in the future). Also, the type it points to is actually an abstract
polymorphic base type, `ObjectBase`; the type you'll need to instantiate
depends on the primitive type you want; for example:

   Sphere *pSphere = new Sphere();
   pSphere->Center = Vector3d(BlenderObjects[i].Center);
   pSphere->Radius = BlenderObjects[i].Radius;
   scene->objects.push_back (pSphere);

or:

   Box *pBox = new Box();
   pBox->bounds[0] = Vector3d(BlenderObjects[i].BottomLeft);
   pBox->bounds[1] = Vector3d(BlenderObjects[i].TopRight);
   scene->objects.push_back (pBox);

or:

   Mesh *pMesh = new Mesh();
   // ...
   scene->objects.push_back (pMesh);

Note that much of the sanity-checking and precomputing of various stuff
is still implemented in the parser, rather than the primitive classes
where it would belong.

Also, in addition to the stuff the parser does while parsing the SDL
file, there are some additional steps required between the parsing and
the invocation of the render engine, such as propagating some
information between parent and child objects, setting up a bounding
hierarchy to speed up rendering, and other stuff like that.

Don't say I didn't warn you...

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3487 days 9 hours and 7 minutes ago]

Sun, 2 Oct 2016 17:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:

> That said, the thing you are looking for is the class `SceneData`
> declared in `source/core/scene/scenedata.h`

All right. I watched this file.

        ~SceneData();

        /// list of all shape objects
        vector<ObjectPtr> objects;
        /// list of all global light sources
        vector<LightSource *> lightSources;
        /**
         *  Create new scene specific data.
         */
        SceneData(GenericFunctionContextFactory* fcf);

A pointer to the object is absent, the light pointer is present.
How to implement my.cpp?

SceneData::SceneData(){};

SceneData *scene = new SceneData();
for (ulong i = 0; i < numberBlenderObjects; i++){
    ObjectPtr *object = new ObjectPtr();
    object = BlenderObjects[i];
    scene -> objects.push_back(object);}

[clipka] Re: My idea: Developers need tips! Help me, plea... [3487 days 12 hours and 4 minutes ago]

Sun, 2 Oct 2016 14:33:27 GMT

Am 01.10.2016 um 20:31 schrieb LanuHum:

> No, I will not understand your code. Very confusing.
> What would be said Gerbert Shildt, if you saw your code?

(BTW, I suspect you mean Herbert Schildt. It seems that "Gerbert Shildt"
is a back-transcription of the name's transcription to Cyrillic script.)

> Macros - evil. It is neither for you.
> 
> Where similar to this?
> 
> //Scene.h
> #include <vector>
> #include "Camera.h"
> #include "Light.h"
> #include "Object.h"
> #include "Pigment.h"
> #include "Normal.h"
> #include "Finish.h"
> #include "Texture.h"
> 
> using namespace std;
> 
> class Scene {
> public:
>     Camera              camera;
>     vector<Light*>      lights;
>     vector<Object*>     static_objects;
>     vector<Object*>     animate_objects;
>     vector<Pigment*>    pigments;
>     vector<Normal*>     normals;
>     vector<Finish*>     finishes;
>     vector<Texture*>    textures;
> 
>                         Scene();
>                         ~Scene();
> };
> 
> In vain I try to.  :((((((((((((((

Didn't I tell you so?

POV-Ray originated 30 (!) years ago as a C project, and still contains
plenty of C-isms to this day.

As I've mentioned numerous times, efforts to clean up the code are in
progress but still far from completed.


That said, the thing you are looking for is the class `SceneData`
declared in `source/core/scene/scenedata.h`, and at that level it's not
/too/ far from what you're looking for -- with the notable exception
that POV-Ray does not manage textures, pigments etc. as indices into a
"library", but rather as direct references (i.e. pointers) to texture
objects. Also, `SceneData` contains a bit more stuff.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3488 days 8 hours and 2 minutes ago]

Sat, 1 Oct 2016 18:35:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> Now I will try to create classes! Thank you. Your support has helped me.

No, I will not understand your code. Very confusing.
What would be said Gerbert Shildt, if you saw your code?
Macros - evil. It is neither for you.

Where similar to this?

//Scene.h
#include <vector>
#include "Camera.h"
#include "Light.h"
#include "Object.h"
#include "Pigment.h"
#include "Normal.h"
#include "Finish.h"
#include "Texture.h"

using namespace std;

class Scene {
public:
    Camera              camera;
    vector<Light*>      lights;
    vector<Object*>     static_objects;
    vector<Object*>     animate_objects;
    vector<Pigment*>    pigments;
    vector<Normal*>     normals;
    vector<Finish*>     finishes;
    vector<Texture*>    textures;

                        Scene();
                        ~Scene();
};

In vain I try to.  :((((((((((((((

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3506 days 6 hours and 37 minutes ago]

Tue, 13 Sep 2016 20:00:00 GMT

clipka, I think I found an error!

#include <python3.3m/Python.h>
#include <iostream>

int main() {
    int len;
    Py_Initialize();
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");
    PyRun_SimpleString("import bpy");

PyRun_SimpleString("bpy.ops.wm.open_mainfile(filepath='/home/leonid/workspace/blender/files_blend/test_so.blend')");
 //read blend-file
    PyObject *pyModuleName = PyUnicode_FromString("bpy");
    PyObject *pyModuleName1 = PyUnicode_FromString("bimport");
    PyObject *pyModule = PyImport_Import(pyModuleName); // import Blender module
    PyObject *pyModule1 = PyImport_Import(pyModuleName1);   // import my module
with parser functions
    PyObject *pyFunc = PyObject_GetAttrString(pyModule1,
"import_blender_scene");
    PyObject *pyArgs = PyTuple_New(1);
    PyTuple_SetItem(pyArgs, 0, pyModule);
    PyObject *pyLen = PyObject_CallObject(pyFunc, pyArgs);
    len = PyLong_AsLong(pyLen);
    std::cout<<len<<std::endl;  // Number of objects in scene (5)
    Py_Finalize();

    std::cout<<"Hello world!"<<std::endl;  //After py_finalize!!!!
    return 0;
}

Konsole:

read blend: /home/leonid/workspace/blender/files_blend/test_so.blend
5
Hello world!
------------------
(program exited with code: 0)




Now I will try to create classes! Thank you. Your support has helped me.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3506 days 8 hours and 17 minutes ago]

Tue, 13 Sep 2016 18:20:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 13.09.2016 um 16:29 schrieb LanuHum:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 12.09.2016 um 22:13 schrieb LanuHum:
> >>> "LanuHum" <Lan### [at] yandexru> wrote:
> >>>>
> >>>> We will look for errors. :))))
> >>>
> >>> :(
> >>> If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
> >>> run. If I do not use the import of bpy, the application lives
> >>
> >> Have you finished your other homework yet?
> >>
> >
> > No. To learn your lesson, I started from scratch. I started all over again.
> > I wrote a single function.
> > The function must import the module, clean it and write "Hello World".
> ...
>
> > Where is the "Hello World"?
>
> Take even another step back: Write a program that does _not_ try to run
> Python at all, and instead just outputs "Hello World" to the standard
> output stream.
>
> How exactly are you running the program in the first place? What is this
> "Konsole"? Why is it writing "Blender quit" when you're testing a
> self-made program?
>
> In MS Visual Studio, if I simply run a "Hello World" program by hitting
> F5, I never see the output because the output window is closed as soon
> as the program exits.
>
> If you have a similar problem, make sure that your program reads a
> character from standard input at the end, so that you need to press a
> key before the window closes.

OK. My OS - Linux.
The first program for Windows is different from the first program for Linux.

For Windows:

#include <iostream>
#include <cstdlib> // for system

int main()
{
    std::cout << "Hello, world!" << std::endl;
    system("pause");
    return 0;
}

For Linux:

#include <iostream>

int main() {
    std::cout<<"Hello world!"<< std::endl;
    return 0;
}

cmd in Widows = konsole, console, terminal, gnome-terminal, lxterminal, xterm in
Linux.
My IDE - Geany, NOT MS Visual Studio! :)))
Compiling object file in IDE:
g++ -Wall -c "%f"
Make binary:
g++ -Wall -o "%e" "%f"
Run:
"./%e"

IDE automatically runs a program from the konsole.
konsole displays the result.
I can run the program manually.
After quit program the console does not close.

This is our first step:

[clipka] Re: My idea: Developers need tips! Help me, plea... [3506 days 9 hours and 28 minutes ago]

Tue, 13 Sep 2016 17:09:45 GMT

Am 13.09.2016 um 16:29 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 12.09.2016 um 22:13 schrieb LanuHum:
>>> "LanuHum" <Lan### [at] yandexru> wrote:
>>>>
>>>> We will look for errors. :))))
>>>
>>> :(
>>> If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
>>> run. If I do not use the import of bpy, the application lives
>>
>> Have you finished your other homework yet?
>>
> 
> No. To learn your lesson, I started from scratch. I started all over again.
> I wrote a single function.
> The function must import the module, clean it and write "Hello World".
...

> Where is the "Hello World"?

Take even another step back: Write a program that does _not_ try to run
Python at all, and instead just outputs "Hello World" to the standard
output stream.

How exactly are you running the program in the first place? What is this
"Konsole"? Why is it writing "Blender quit" when you're testing a
self-made program?

In MS Visual Studio, if I simply run a "Hello World" program by hitting
F5, I never see the output because the output window is closed as soon
as the program exits.

If you have a similar problem, make sure that your program reads a
character from standard input at the end, so that you need to press a
key before the window closes.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3506 days 12 hours and 2 minutes ago]

Tue, 13 Sep 2016 14:35:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 12.09.2016 um 22:13 schrieb LanuHum:
> > "LanuHum" <Lan### [at] yandexru> wrote:
> >>
> >> We will look for errors. :))))
> >
> > :(
> > If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
> > run. If I do not use the import of bpy, the application lives
>
> Have you finished your other homework yet?
>

No. To learn your lesson, I started from scratch. I started all over again.
I wrote a single function.
The function must import the module, clean it and write "Hello World".

#include <python3.3m/Python.h>
#include <iostream>

int main() {
    Py_Initialize();
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");
    PyObject *pyModuleName = PyUnicode_FromString("bimport");
    PyObject *pyModule = PyImport_Import(pyModuleName);
    Py_DECREF(pyModuleName);
    Py_DECREF(pyModule);
    Py_Finalize();
    std::cout<<"Hello world!";
    return 0;
}

The "bimport" module is only one row : import bpy

make and run.

Konsole wrote:

Blender quit
------------------
(program exited with code: 0)
Press return to continue...

Where is the "Hello World"?

I can rearrange some places line:

    Py_DECREF(pyModule);
    Py_DECREF(pyModuleName);

same result.

There is also need classes? In my opinion, it is a bug, and need a new idea.

[clipka] Re: My idea: Developers need tips! Help me, plea... [3507 days 5 hours and 45 minutes ago]

Mon, 12 Sep 2016 20:52:21 GMT

Am 12.09.2016 um 22:13 schrieb LanuHum:
> "LanuHum" <Lan### [at] yandexru> wrote:
>>
>> We will look for errors. :))))
> 
> :(
> If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
> run. If I do not use the import of bpy, the application lives

Have you finished your other homework yet?

I wouldn't be surprised if unreleased stuff allocated by Py_Whatever()
might cause crashes upon calling PyFinalize().

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3507 days 6 hours and 22 minutes ago]

Mon, 12 Sep 2016 20:15:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
>
> We will look for errors. :))))

:(
If I uncommented Py_Finalize(), application crash when the command Py_Finalize()
run. If I do not use the import of bpy, the application lives

https://docs.python.org/3.5/c-api/init.html

Bugs and caveats: The destruction of modules and objects in modules is done in
random order; this may cause destructors (__del__() methods) to fail when they
depend on other objects (even functions) or modules. Dynamically loaded
extension modules loaded by Python are not unloaded. Small amounts of memory
allocated by the Python interpreter may not be freed (if you find a leak, please
report it). Memory tied up in circular references between objects is not freed.
Some memory allocated by extension modules may not be freed. Some extensions may
not work properly if their initialization routine is called more than once; this
can happen if an application calls Py_Initialize() and Py_Finalize() more than
once.

[clipka] Re: My idea: Developers need tips! Help me, plea... [3507 days 10 hours and 56 minutes ago]

Mon, 12 Sep 2016 15:41:30 GMT

Am 12.09.2016 um 16:20 schrieb Mr:

> Despite the "poor but improving" modularity of POV, Clipka,

Hah! Just recently I've managed to cut off last appendages by which the
VFE had invaded the render engine modules; so there's actually a silver
lining at the horizon.


> would some kind of root to grow this module on, already exist in the shape of
> POV-Ray's "GUI-Extension API"?

I must confess that I have no idea. IIRC the whole GUI-Extension thing
is specific to POV-Ray for Windows, and I've never had a close look at
it. My naive assumption would be that it is just the other way around:
An interface to plug stuff into POV-Ray, not to plug POV-Ray into stuff.

I think I recall that some modelers were written as a GUI extension and
were somehow able to start renders and such; but I'm 99% sure the data
transfer always used .pov files.


> Reading the following discussion,
> http://news.povray.org/povray.beta-test/thread/%3C461768ac%241@news.povray.org%3E/
> ..... Hugo , who has long been the main user of this GUI-extension with Bishop 3D
> might welcome some feedback?

The request for feedback had been directed at Chris; I have no idea what
became of it. But today, the feedback would presumably be "Here, be
invited to look at the code at GitHub, and see what you can do with it."

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3507 days 10 hours and 57 minutes ago]

Mon, 12 Sep 2016 15:40:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 12.09.2016 um 16:04 schrieb LanuHum:
>
> >> One memory leak eliminated. I'll have a look whether I can find some more.
> >
> > Thank you. Yes, I'm just learning. If I close the app - the memory is freed.
>
> When an application closes, the operating system always reclaims all of
> the allocated memory, by force so to speak.
>
> > Memory takes each successive press of a button.
> > Button believes the number of vertices.
> > Memory: 1760
> > Start app. Memory: 1760
> > vertices number = 983042
> > Press button "Render" . Memory: 2380
> > Press button "Render" . Memory: 2750
> > Press button "Render" . Memory: 3100
> > Press button "Render" . Memory: 3470
> > What you need to be reset. Which variable is stored. I see no reason.
>
> I've seen plenty ;)

We will look for errors. :))))

[clipka] Re: My idea: Developers need tips! Help me, plea... [3507 days 11 hours and 9 minutes ago]

Mon, 12 Sep 2016 15:28:36 GMT

Am 12.09.2016 um 16:04 schrieb LanuHum:

>> One memory leak eliminated. I'll have a look whether I can find some more.
> 
> Thank you. Yes, I'm just learning. If I close the app - the memory is freed.

When an application closes, the operating system always reclaims all of
the allocated memory, by force so to speak.

> Memory takes each successive press of a button.
> Button believes the number of vertices.
> Memory: 1760
> Start app. Memory: 1760
> vertices number = 983042
> Press button "Render" . Memory: 2380
> Press button "Render" . Memory: 2750
> Press button "Render" . Memory: 3100
> Press button "Render" . Memory: 3470
> What you need to be reset. Which variable is stored. I see no reason.

I've seen plenty ;)

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3507 days 11 hours and 17 minutes ago]

Mon, 12 Sep 2016 15:20:00 GMT

"Mr" <nomail@nomail> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > I started to learn programming language C ++.
> > To transfer data from Blender in Povray, we use files
> > My idea: to give up files.
> >
> > How will it work?
> >
> > #include <iostream>
> > #include <string>
> > #include <Python.h>
> > #include <fx.h>
> >
> > [...]
> > I want to ask: I can anyone help tips?
>
>
> RNA being the data architecture in Blender:
> https://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/RNA
>
> Blender does have a C++ RNA API exposing all the program data.
> It is used by the Cycles rendering engine, which uses Python only for it's
> graphical user interface.
>
> Are you using the python version of this API instead?
> So, maybe a faster version of what you're trying to achieve already exists, and
> what would need developing would rather be the POV-Ray module.
>
> This module would just use the existing API from a running Blender session
> acting as a mere library to read the data.
>
> Despite the "poor but improving" modularity of POV, Clipka,
> would some kind of root to grow this module on, already exist in the shape of
> POV-Ray's "GUI-Extension API"?
>
>
> As much as I was also advised not to go there in the immediate future, with my
> currently *inexistant* C programming skills, Probably Lanuhum is actually able
> to get somewhere faster, even as a first C project, given his motivation and
> fast learning skills.
>
> Reading the following discussion,
> http://news.povray.org/povray.beta-test/thread/%3C461768ac%241@news.povray.org%3E/
> .... Hugo , who has long been the main user of this GUI-extension with Bishop 3D
> might welcome some feedback?
>
> It might be beneficial to several communities if the updating of POV-Ray's
> GUI-Extension API could then be used as the foundation to create the said
> module... Do you think it could?

> > How will it work?

I do not want and I can not study the blender code. Blender always unstable, and
I do not have the knowledge to understand the code hundred meters. Blender can
not create a GUI, and how to create a Python module. This allows cmake. I get
bpy.so library. I can work without running the blender with this library, Using
any development environment that supports python or any text editor. But I can
also run the script using C++. C++ runs a script, the script calls the bpy.so
module and transmits the data in C++. My GUI (fx.h) causes Povray and sends data
to it. Povray requires a patch, which will need to write.
:)))

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3507 days 11 hours and 52 minutes ago]

Mon, 12 Sep 2016 14:45:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 11.09.2016 um 22:06 schrieb LanuHum:
>
> > https://github.com/Lanuhum/Blender-C-
>
> Some more comments:
>
>
> All the PyObject* items in py2c.cpp:
>
> First of all, you're using global variables, which you shouldn't use in
> C++ programs. You should wrap all the stuff in py2c.cpp into a class.
>
> Then, every time you set them to some value returned by PyWhatThe_Foo(),
> you're receiving a pointer to data residing... well, /somewhere/. Nobody
> knows. And, more importantly, given that it is /probably/ dynamically
> allocated, nobody knows who is responsible for /releasing/ the memory.
> And /how/ to release it. The <Python.h> functions may be striaghtforward
> C code, in which case you need to release the stuff using `free()`. Or
> it may be C++ code, in which case you need to release it using
> `delete[]` (most certainly not `delete`; subtle but important difference
> there). Or <Python.h> may provide a dedicated function to dispose of it.
> Obviously you're not really sure or aware of this issue either, because
> you never invoke any of these mechanisms.
>
> There is some code at the end of parse_blend() that /looks/ like it was
> intended to do the trick, but you commented it out. Worse yet, it
> wouldn't even be sufficient.
>
> *Every* time you assign something to one of these variables (and also
> when the program exits), the previous content gets lost, and the memory
> it pointed to remains in limbo: Your memory holes are legion.
>
> What you (presumably) need to to is call PyDECREF() *every* time before
> you *overwrite* one of those PyObject* variables.
>
>
> You may want to have a look at boost.python, which seems to encapsulate
> the Python API a bit better for use in C++, most notably allowing the
> use of smart pointers rather than classic C pointers. Smart pointers
> automatically release the data they point to when you assign a new value
> to the smart pointer, or even when the variable goes out of scope.
> (They're even smart enough to /not/ release data if another copy of the
> smart pointer still refers to the data.)
>
>
> PyName_AsName():
>
> Same problem as above, but even worse: You need to pass the data out of
> the function, so you can't just call PyDECRREF() on the data (if that's
> even the proper way of releasing char* data returned by the Python API).
> I would recopmmend constructing a std::string from it (creating a copy
> of its contents), and call the adequate memory release function
> immediately. You can then return the std::string, which will save the
> caller from the task of pointer handling.
>
>
> parse_verts():
>
> You're using a vector<double> to store three coordinates. This is
> inefficient: vector<> is designed to store dynamic arrays, /not/ what
> mathematicians would call a vector. Instead, simply use:
>
>     double coord[3];
>
> You can leave the remainder of the function entirely unchanged.
>
>
> parse_faces():
>
> Same deal as above for the `face` variable.
>
>
> ImageWindow:
>
> Here you're solving the global variables the right way: By making it a
> class, and working with an instance of it. /But/ you're falling short:
> Your constructor constructs an assload of data using `new`, but the
> destructor only releases three of those fields using `delete`. Also, for
> some of the stuff you're creating I wonder whether you're ever properly
> hooking it up to other stuff. Maybe it's a quirk of <fx.h>, but to me
> every "new" without an assignment to its left-hand side (or something
> else that stores its result value) reeks of a serious coding error.
>
>
> ImageWindow::onCmdRender():
>
> Beware that clock_gettime is /not/ portable.
>
>
> Well, I guess that should suffice for starters. I shall warn you though:
> I suspect you'll still have a looooooong way ahead of you, and I won't
> be able to provide this type of support on a regular basis.



Thank you so much! This is very useful information.

I will not always stupid! :))))

Once I was afraid python, now I'm not afraid of him.

I will learn and will help you.



>
> I don't mean to discourage you, but seriously: Do you /really/ feel up
> to this challenge you have given yourself? This is supposed to evolve
> into an interface between Blender and POV-Ray's render engine, right?

Yes. I would like to make an elephant out of a fly.
Now the data transfer takes a very long time. Write file, parse file...
I want to get rid of it.

[Mr] Re: My idea: Developers need tips! Help me, plea... [3507 days 12 hours and 12 minutes ago]

Mon, 12 Sep 2016 14:25:01 GMT

"LanuHum" <Lan### [at] yandexru> wrote:
> I started to learn programming language C ++.
> To transfer data from Blender in Povray, we use files
> My idea: to give up files.
>
> How will it work?
>
> #include <iostream>
> #include <string>
> #include <Python.h>
> #include <fx.h>
>
> [...]
> I want to ask: I can anyone help tips?

RNA being the data architecture in Blender:
https://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/RNA

Blender does have a C++ RNA API exposing all the program data.
It is used by the Cycles rendering engine, which uses Python only for it's
graphical user interface.

Are you using the python version of this API instead?
So, maybe a faster version of what you're trying to achieve already exists, and
what would need developing would rather be the POV-Ray module.

This module would just use the existing API from a running Blender session
acting as a mere library to read the data.

Despite the "poor but improving" modularity of POV, Clipka,
would some kind of root to grow this module on, already exist in the shape of
POV-Ray's "GUI-Extension API"?

As much as I was also advised not to go there in the immediate future, with my
currently *inexistant* C programming skills, Probably Lanuhum is actually able
to get somewhere faster, even as a first C project, given his motivation and
fast learning skills.

Reading the following discussion,
http://news.povray.org/povray.beta-test/thread/%3C461768ac%241@news.povray.org%3E/
.... Hugo , who has long been the main user of this GUI-extension with Bishop 3D
might welcome some feedback?

It might be beneficial to several communities if the updating of POV-Ray's
GUI-Extension API could then be used as the foundation to create the said
module... Do you think it could?

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3507 days 12 hours and 32 minutes ago]

Mon, 12 Sep 2016 14:05:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 11.09.2016 um 22:06 schrieb LanuHum:
> > We continue to
> > https://github.com/Lanuhum/Blender-C-
> > Seeking a memory leak.
>
> The name of the repo is poorly chosen: Pasting the corresponding link
> into plain text such as a mail, software that auto-detects links in
> plain text may think the trailing `-` isn't part of the link (this is
> quite obviously the case with Thunderbird).
>
> I would recommend renaming the repo to, e.g., "Blender-Cpp".
>

I gave the name of the repository blender-C++
I did not know that github does not understand plus plus
Plus, plus, he was replaced by minus.
I tried renaming, but the button "Rename" is not active. :(
:)
> > If you decide the problem - I will continue. I'll connect povray with blender.
> > :)))
>
> You're not very familiar with C++, are you?
>
> One property of C++ is that there is no garbage collection in the
> language itself, and you'll have to actively release all memory you
> allocate. Thus, in the main() function,
>
>     int main(int argc,char *argv[]){
>         FXApp application("foxray",FXString::null);
>         application.init(argc,argv);
>         new ImageWindow(&application);
>         application.create();
>         return application.run();
>     }
>
> the `new ImageWindow(&application);` will allocate memory for, and
> create, an object of type `ImageWindow`, but makes no provision to
> remember the address of the memory allocated, so there is no way to
> release the memory later.
>
> You probably want to do something like this:
>
>     ImageWindow myWindow = new ImageWindow(...);
>     ...
>     delete myWindow;
>
> One memory leak eliminated. I'll have a look whether I can find some more.

Thank you. Yes, I'm just learning. If I close the app - the memory is freed.
Memory takes each successive press of a button.
Button believes the number of vertices.
Memory: 1760
Start app. Memory: 1760
vertices number = 983042
Press button "Render" . Memory: 2380
Press button "Render" . Memory: 2750
Press button "Render" . Memory: 3100
Press button "Render" . Memory: 3470
What you need to be reset. Which variable is stored. I see no reason.

[clipka] Re: My idea: Developers need tips! Help me, plea... [3508 days 4 hours and 18 minutes ago]

Sun, 11 Sep 2016 22:19:02 GMT

Am 11.09.2016 um 22:06 schrieb LanuHum:

> https://github.com/Lanuhum/Blender-C-

Some more comments:


All the PyObject* items in py2c.cpp:

First of all, you're using global variables, which you shouldn't use in
C++ programs. You should wrap all the stuff in py2c.cpp into a class.

Then, every time you set them to some value returned by PyWhatThe_Foo(),
you're receiving a pointer to data residing... well, /somewhere/. Nobody
knows. And, more importantly, given that it is /probably/ dynamically
allocated, nobody knows who is responsible for /releasing/ the memory.
And /how/ to release it. The <Python.h> functions may be striaghtforward
C code, in which case you need to release the stuff using `free()`. Or
it may be C++ code, in which case you need to release it using
`delete[]` (most certainly not `delete`; subtle but important difference
there). Or <Python.h> may provide a dedicated function to dispose of it.
Obviously you're not really sure or aware of this issue either, because
you never invoke any of these mechanisms.

There is some code at the end of parse_blend() that /looks/ like it was
intended to do the trick, but you commented it out. Worse yet, it
wouldn't even be sufficient.

*Every* time you assign something to one of these variables (and also
when the program exits), the previous content gets lost, and the memory
it pointed to remains in limbo: Your memory holes are legion.

What you (presumably) need to to is call PyDECREF() *every* time before
you *overwrite* one of those PyObject* variables.


You may want to have a look at boost.python, which seems to encapsulate
the Python API a bit better for use in C++, most notably allowing the
use of smart pointers rather than classic C pointers. Smart pointers
automatically release the data they point to when you assign a new value
to the smart pointer, or even when the variable goes out of scope.
(They're even smart enough to /not/ release data if another copy of the
smart pointer still refers to the data.)


PyName_AsName():

Same problem as above, but even worse: You need to pass the data out of
the function, so you can't just call PyDECRREF() on the data (if that's
even the proper way of releasing char* data returned by the Python API).
I would recopmmend constructing a std::string from it (creating a copy
of its contents), and call the adequate memory release function
immediately. You can then return the std::string, which will save the
caller from the task of pointer handling.


parse_verts():

You're using a vector<double> to store three coordinates. This is
inefficient: vector<> is designed to store dynamic arrays, /not/ what
mathematicians would call a vector. Instead, simply use:

    double coord[3];

You can leave the remainder of the function entirely unchanged.


parse_faces():

Same deal as above for the `face` variable.


ImageWindow:

Here you're solving the global variables the right way: By making it a
class, and working with an instance of it. /But/ you're falling short:
Your constructor constructs an assload of data using `new`, but the
destructor only releases three of those fields using `delete`. Also, for
some of the stuff you're creating I wonder whether you're ever properly
hooking it up to other stuff. Maybe it's a quirk of <fx.h>, but to me
every "new" without an assignment to its left-hand side (or something
else that stores its result value) reeks of a serious coding error.


ImageWindow::onCmdRender():

Beware that clock_gettime is /not/ portable.


Well, I guess that should suffice for starters. I shall warn you though:
I suspect you'll still have a looooooong way ahead of you, and I won't
be able to provide this type of support on a regular basis.

I don't mean to discourage you, but seriously: Do you /really/ feel up
to this challenge you have given yourself? This is supposed to evolve
into an interface between Blender and POV-Ray's render engine, right?

[clipka] Re: My idea: Developers need tips! Help me, plea... [3508 days 5 hours and 37 minutes ago]

Sun, 11 Sep 2016 21:00:03 GMT

Am 11.09.2016 um 22:06 schrieb LanuHum:
> We continue to
> https://github.com/Lanuhum/Blender-C-
> Seeking a memory leak.

The name of the repo is poorly chosen: Pasting the corresponding link
into plain text such as a mail, software that auto-detects links in
plain text may think the trailing `-` isn't part of the link (this is
quite obviously the case with Thunderbird).

I would recommend renaming the repo to, e.g., "Blender-Cpp".

> If you decide the problem - I will continue. I'll connect povray with blender.
> :)))

You're not very familiar with C++, are you?

One property of C++ is that there is no garbage collection in the
language itself, and you'll have to actively release all memory you
allocate. Thus, in the main() function,

    int main(int argc,char *argv[]){
        FXApp application("foxray",FXString::null);
        application.init(argc,argv);
        new ImageWindow(&application);
        application.create();
        return application.run();
    }

the `new ImageWindow(&application);` will allocate memory for, and
create, an object of type `ImageWindow`, but makes no provision to
remember the address of the memory allocated, so there is no way to
release the memory later.

You probably want to do something like this:

    ImageWindow myWindow = new ImageWindow(...);
    ...
    delete myWindow;

One memory leak eliminated. I'll have a look whether I can find some more.

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3508 days 6 hours and 27 minutes ago]

Sun, 11 Sep 2016 20:10:00 GMT

We continue to
https://github.com/Lanuhum/Blender-C-
Seeking a memory leak.
If you decide the problem - I will continue. I'll connect povray with blender.
:)))

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3556 days 13 hours and 7 minutes ago]

Mon, 25 Jul 2016 13:30:00 GMT

clipka <ano### [at] anonymousorg> wrote:

>
> Unless -- and I suspect that's actually the case -- I'm completely
> misunderstanding you.
>

Do not rush. I had no time to explain everything.
Till tomorrow. :))))

[clipka] Re: My idea: Developers need tips! Help me, plea... [3557 days 6 hours and 23 minutes ago]

Sun, 24 Jul 2016 20:14:25 GMT

Am 24.07.2016 um 20:41 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 24.07.2016 um 19:31 schrieb LanuHum:
>>>
>>> I started to learn programming language C ++.
>>> To transfer data from Blender in Povray, we use files
>>> My idea: to give up files.
>>>
>>> How will it work?
>>
>> Uh... I understand very little of what that piece of code is supposed to
>> do, most probably because of all the "PyWhatever" functions which, I
>> presume, are an interface to Python. So what you've written there is
>> probaly a wild mix of C++ and Python in C++-disguise.
> 
> You do not need to understand it. I figure it out.

"Believe me, I know what I'm doing"... now that's something that tends
to make me suspicious. I prefer to have at least some /basic/
understanding of what's going on.

(Also, if you figure it out, why do you need any help? ;))

> This is just an example of a model

That is a "scene file"? You intend to use C++ as a scene language?

Well, you'd need a C++ compiler to render a scene then. I doubt whether
that would be portable enough -- or even provide a reasonable speed
improvement over a parsed scene; after all, you'll replace a parser for
a comparatively simple domain-specific language with a parser for a
mind-bogglingly complex generic-purpose language.

Also, that would still not get you rid of files, since instead of
generating SDL files you'd then have to generate C++ files.

Unless -- and I suspect that's actually the case -- I'm completely
misunderstanding you.

>> This is currently not possible, because files are the one and only way
>> to transmit the necessary data into POV-Ray (in the form of INI and SDL
>> files, as well as image map files and the like) and back out of it (in
>> the form of image files).
> 
> Oh, that's interesting. Why is it impossible? There is no Povray scene?
> scene = new scene  NO?
> And where the parser loads the data?
> Povray causes parser. The parser is doing what?
> You can prevent the call of the parser, and cause my code.
> My code does the work of the parser.
> What is the problem?
> It is only necessary to correct code PovRay:
> if filepov:
> bla-bla-bla
> if fileblend:
> bla-bla-bla

That's how it /should/ work (and even just a naive picture thereof).

But parsing is only one part of the job -- you also need to start up and
manage the render threads, and control the assembly of their results
into an image. Not to mention photon shooting tasks, radiosity pretrace
tasks, and some such.

And the code performing that particular functionality (called the
"back-end"(*)) is still not well delineated from the render engine (aka
the "core"), the parser, and the user-defined function execution engine
(aka the "virtual machine", or "vm" for short).

It is even still interwoven with the user interface (aka the
"front-end"), or more precisely one particular piece thereof (known as
the "virtual front-end" or "vfe"); I like to consider that piece of code
my arch-nemesis in the quest for modularizing POV-Ray.

(*In POV-Ray 3.7.0, the delineation between back-end, parser, core and
vm was even worse than that, and the term "back-end" referred to the
entirety of all those modules.)

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3557 days 7 hours and 32 minutes ago]

Sun, 24 Jul 2016 19:05:00 GMT

"Bald Eagle" <cre### [at] netscapenet> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> > Uh... I understand very little of what that piece of code is supposed to
> > do, most probably because of all the "PyWhatever" functions which, I
> > presume, are an interface to Python. So what you've written there is
> > probaly a wild mix of C++ and Python in C++-disguise.
>
> Sounds kinda like
> http://zulko.github.io/blog/2014/11/13/things-you-can-do-with-python-and-pov-ray/
>
> https://github.com/Zulko/vapory
>
> https://pypi.python.org/pypi/Vapory/0.1.0
>
> etc.   search vapory + povray for more

No. They create .pov file. I know how it is better. I do not need it. Read my
previous post. Blender.so - python module.I will upload it in a blender file
with animation and immediately upload data to render.The process will take place
within the program at a rate of C ++

[LanuHum] Re: My idea: Developers need tips! Help me, plea... [3557 days 7 hours and 52 minutes ago]

Sun, 24 Jul 2016 18:45:00 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 24.07.2016 um 19:31 schrieb LanuHum:
> >
> > I started to learn programming language C ++.
> > To transfer data from Blender in Povray, we use files
> > My idea: to give up files.
> >
> > How will it work?
>
> Uh... I understand very little of what that piece of code is supposed to
> do, most probably because of all the "PyWhatever" functions which, I
> presume, are an interface to Python. So what you've written there is
> probaly a wild mix of C++ and Python in C++-disguise.
>

You do not need to understand it. I figure it out.
This is just an example of a model

>
> This is currently not possible, because files are the one and only way
> to transmit the necessary data into POV-Ray (in the form of INI and SDL
> files, as well as image map files and the like) and back out of it (in
> the form of image files).
>

Oh, that's interesting. Why is it impossible? There is no Povray scene?
scene = new scene  NO?
And where the parser loads the data?
Povray causes parser. The parser is doing what?
You can prevent the call of the parser, and cause my code.
My code does the work of the parser.
What is the problem?
It is only necessary to correct code PovRay:
if filepov:
bla-bla-bla
if fileblend:
bla-bla-bla

[Bald Eagle] Re: My idea: Developers need tips! Help me, plea... [3557 days 8 hours and 12 minutes ago]

Sun, 24 Jul 2016 18:25:01 GMT

clipka <ano### [at] anonymousorg> wrote:

> Uh... I understand very little of what that piece of code is supposed to
> do, most probably because of all the "PyWhatever" functions which, I
> presume, are an interface to Python. So what you've written there is
> probaly a wild mix of C++ and Python in C++-disguise.

Sounds kinda like
http://zulko.github.io/blog/2014/11/13/things-you-can-do-with-python-and-pov-ray/

https://github.com/Zulko/vapory

https://pypi.python.org/pypi/Vapory/0.1.0

etc.   search vapory + povray for more

[clipka] Re: My idea: Developers need tips! Help me, plea... [3557 days 8 hours and 31 minutes ago]

Sun, 24 Jul 2016 18:06:17 GMT

Am 24.07.2016 um 19:31 schrieb LanuHum:
> 
> I started to learn programming language C ++.
> To transfer data from Blender in Povray, we use files
> My idea: to give up files.
> 
> How will it work?

Uh... I understand very little of what that piece of code is supposed to
do, most probably because of all the "PyWhatever" functions which, I
presume, are an interface to Python. So what you've written there is
probaly a wild mix of C++ and Python in C++-disguise.


I understand that your goal is to transfer data between Blender and
POV-Ray without using files (as in, "the things that get written to the
hard drive").

This is currently not possible, because files are the one and only way
to transmit the necessary data into POV-Ray (in the form of INI and SDL
files, as well as image map files and the like) and back out of it (in
the form of image files).

There is ongoing work to modularize POV-Ray enough so that it can be
called as a kind of library from other applications, allowing to bypass
the parser and the image file output, but that work is far from finished.

[LanuHum] My idea: Developers need tips! Help me, please! [3557 days 9 hours and 2 minutes ago]

Sun, 24 Jul 2016 17:35:01 GMT

I started to learn programming language C ++.
To transfer data from Blender in Povray, we use files
My idea: to give up files.

How will it work?

#include <iostream>
#include <string>
#include <Python.h>
#include <fx.h>



int grab(int, char **) {
    PyObject *mName, *pModule, *pFunc, *pArgs, *pValue;
    PyObject *cResult, *pName;
    Py_Initialize();
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");
    PyRun_SimpleString("from bimport import hello");
    mName = PyUnicode_FromString("bimport");
    char fName[] = "hello";
    pModule = PyImport_Import(mName);
    pFunc = PyObject_GetAttrString(pModule, fName);
    int i = 1;
    long nL = 5;
    PyObject* l = PyLong_FromLong(nL);
    pArgs = PyTuple_New(i);
    PyTuple_SetItem(pArgs, 0, l);
    pValue = PyObject_CallObject(pFunc, pArgs);
    cResult = PyTuple_GetItem(pValue,0);
    pName = PyObject_Repr(cResult);
    pName = PyUnicode_AsEncodedString(pName, "utf-8","Error ~");
    const char *Hello = PyBytes_AS_STRING(pName);
    std::cout << Hello << std::endl;
    Py_Finalize();
    return 0;
}
 ....................................
 ....................................
 ....................................

int main(int argc,char *argv[]){
  FXApp application("Povray animator","Test");
  application.init(argc,argv);
  Awindow* window=new Awindow(&application);
  application.addSignal(SIGINT,window,Awindow::ID_QUIT);
  application.create();
  if(argc>1) window->loadimage(argv[1]);
  return application.run();
  }

Also see the attachment.

I want to ask: I can anyone help tips?

[Bridgeofstraws] Re: MegaPOV for DOS [3996 days 1 hour and 32 minutes ago]

Wed, 13 May 2015 01:05:01 GMT

Hi,

I've managed to compile POV-Ray 3.62 and MegaPOV 1.21 for DOS.  If anyone wants
them post back here.

Michael

[Bridgeofstraws] MegaPOV for DOS [4001 days 7 hours and 22 minutes ago]

Thu, 7 May 2015 19:15:00 GMT

Hi folks,

I have a bit of an unique request.  Would anyone happen to have MegaPOV for DOS
anywhere.  I found
https://web.archive.org/web/20030103112533/http://megapov.inetart.net/download.html
which has a link for MegaPOV 1.0 but it unfortunately doesn't work anymore.  I'd
be grateful if anyone still has a version.  For my situation DOS is a
requirement, so please no suggestions for windows or linux.  Alternatively if
anyone can explain how the latest MegaPOV sources can be compiled with DJGPP
that would be okay too.

Thanks very much,
Michael

[CAS] Re: post_process filters source code - filters.z... [4193 days 16 hours and 52 minutes ago]

Mon, 27 Oct 2014 09:45:07 GMT

Chris Huff <chr### [at] yahoocom> wrote:
> Due to problems with the .zip version, here is the .sit version. If you
> don't have StuffIt Expander, you can get it here:
> http://www.aladdinsys.com/expander/expander_win_login.html
>
> --
> Christopher James Huff - Personal e-mail: chr### [at] yahoocom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://chrishuff.dhs.org/
> TAG Web page: http://tag.povray.org/

Dear Christopher James Huff,I want to consult a question:
I want to output the intersection point I(x,y,z) in x(ix,iy), y(ix,iy) and
z(ix,iy) as an ancillary image.I only find the function of PP_Depth in
"pprocess.inc" ,and I did not find the function of output the intersection point
I(x,y,z).Can you give me an example about output the intersection point or offer
an advice? So sorry to disturb you. Expecting you reply.
#version unofficial MegaPov 1.1;

#include "pprocess.inc"
“global_settings {

  assumed_gamma 1.0

  post_process{

    PP_Depth(DepthMin,DepthMax)

    save_file concat("pp_",output_filename(0))

  }

}”

Regards

[clipka] Re: Ancient POVMS docs [4337 days 6 hours and 57 minutes ago]

Thu, 5 Jun 2014 19:40:44 GMT

Am 05.06.2014 17:54, schrieb Thorsten Froehlich:
> I was digging in some old messages, and this might help clarify some
> developments. There are actually more messages, but at the time I used a
> different newsreader software and the backups are elsewhere...

Thanks Thorsten, I'll see to it that the information contained therein 
somehow finds its way into the repo.

[Thorsten Froehlich] Ancient POVMS docs [4337 days 10 hours and 43 minutes ago]

Thu, 5 Jun 2014 15:54:44 GMT

I was digging in some old messages, and this might help clarify some 
developments. There are actually more messages, but at the time I used a 
different newsreader software and the backups are elsewhere...

Keep in mind that some information will be outdated!!

-------- Original Message --------
Subject: 	POVMS C++ interface posted
Date: 	Sat, 25 Sep 1999 18:52:25 -0500
From: 	Thorsten Froehlich
Newsgroups: 	private.pov-team

Hello,

I have posted an archive with the current C++ interface classes for the
POVMS. They hide the POVMS C interface behind standard C++ classes so you
only need to deal with these classes and not with actual POVMS data
sttuctres or calls.  Ther are, however, a few open ends where a C++
implementation does not make any sense. You will still need to install
standard POVMS C interface receive handler functions for messages, but with
the POVMS message data structures received you can easily create C++
interface objects out of them by calling a conversion constructor.
Also notice that you need to call the destructors of each of the C++
objects, contrary to the POVMS interface which takes over the ownership when
data is added to some structures. For example, while you would do this in
the C interface:

void myFunc(POVMSObjectPtr object, POVMSType key, char *str)
{
   POVMSAttribute attr;
   int ret;

   ret = POVMSAttr_New(&attr);
   if(ret == kNoErr)
     ret = POVMSAttr_Set(&attr, kPOVMSType_CString,
                         (void *)str, strlen(str) + 1);
   if(ret == kNoErr)
     ret = POVMSObject_Set(object, &attr, key);
}

It will look like this using the C++ interface:

void myFunc(POVMS_Object& object, POVMSType key, char *str)
{
   POVMS_Attribute attr;

   try
   {
     attr.Set(kPOVMSType_CString,
             (void *)str, strlen(str) + 1);

     object.Set(attr, key);
   }
   catch(int ret)
   {
     // ...
   }
}

Or, with a dynamic allocation like this:

void myFunc(POVMS_Object& object, POVMSType key, char *str)
{
   POVMS_Attribute *attr = new POVMS_Attribute;

   try
   {
     attr->Set(kPOVMSType_CString,
             (void *)str, strlen(str) + 1);

     object.Set(*attr, key);
   }
   catch(int ret)
   {
     // ...
   }

   delete attr;
}

Notice, however, that the following will _not_ work as expected:

void myFunc(POVMS_Object& object, POVMSType key, POVMSType key2, char *str)
{
   POVMS_Attribute *attr = new POVMS_Attribute;

   try
   {
     attr->Set(kPOVMSType_CString,
             (void *)str, strlen(str) + 1);

     object.Set(*attr, key);

     object.Set(*attr, key2); // won't work

     attr->Set(kPOVMSType_CString,
             (void *)str, strlen(str) + 1);

     object.Set(*attr, key2); // will work
  }
   catch(int ret)
   {
     // ...
   }

   delete attr;
}

The reason for this is that once the POVMS data has been added to an object
it belongs to that object. So after the first call to object.Set the POVMS
data the C++ object contains is empty. The second call to object.Set will
simply throw an exception that the data passed is empty.
Notice that you can reuse the object as done in the third call to
object.Set.  Also notice that there won't be memory leaks if you call
attr->Set several times, but each time the old data will be replaced.

Another note: The C++ implementation will throw exceptions. Currently all
exception data is of type int.

For now I haven't written any documentation for the C++ class part, in most
parts it work exactly like the C implemenation and I have noted all
differences.
I will try to write docs, but midterm exams are coming nearer and it might
take until late October or so. :-(

It is also very important to note that I have _not_ used the classes myself
so far, so there will likely be problems left. Please let me know of any
unexpected behaviour!

      Thorsten

-------- Original Message --------
Subject: 	Re: POVMS
Date: 	Thu, 12 Apr 2001 13:18:25 -0500
From: 	Thorsten Froehlich
To: 	Chris Cason

 > Could you please show me how I can use POVMS to retrieve the error line,
 > column, and token from POVMS after a parsing error ? I can see you send
 > them via Where_Error (), but I have no idea how to get them from the
 > Windows side.

Well, you can get the file and line number easily.  Unfortunately you
cannot get the column where the error occurred because this information
is not always available.  It could be added and have a default value, of
course.  I am not sure what the specific token that caused the error
would be useful for as it is part of the error message already.

This is the code I use on the Mac:

POVMS_InstallReceiver(Mac__ReceiveHandler,
                       kPOVMsgClass_RenderOutput,
                       kPOVMSType_WildCard); // you will get i.e.
                                             // kPOVMsgIdent_Error,
                                             // kPOVMsgIdent_FatalError,
                                             // kPOVMsgIdent_Warning,
                                             // kPOVMsgIdent_Debug

int Mac__ReceiveHandler(POVMSObjectPtr msg,
                         POVMSObjectPtr result,
                         int mode)
{
  POVMSAttribute attr;
  POVMSType hid;
  Str255 fname = kEmptyString;
  FSSpec file;
  Handle h;
  long l = 0;
  long s = 0;
  int ret = 0;
  int line;

  ret = POVMSObject_Get(msg, &attr, kPOVMSMessageIdentID);
  if(ret == 0)
  {
   l = sizeof(POVMSType);
   ret = POVMSAttr_Get(&attr, kPOVMSType_Type, (void *)(&hid), &l);
   (void)POVMSAttr_Delete(&attr);
  }
  if(ret == 0)
  {
   switch(hid)
   {
    case kPOVMsgIdent_Error:
    case kPOVMsgIdent_FatalError:
     ret = POVMSObject_Get(msg, &attr, kPOVAttrib_EnglishText);
     if(ret == 0)
      ret = POVMSAttr_Size(&attr, &l);
     if(ret == 0)
     {
      h = NewHandle(l);
      if(h == NULL)
       ret = -2;
     }
     if(ret == 0)
     {
      HLock(h);
      ret = POVMSAttr_Get(&attr, kPOVMSType_CString, (void *)(*h), &l);
      HUnlock(h);
     }
     if(ret == 0)
      (void)POVMSAttr_Delete(&attr);
     if(POVMSObject_Get(msg, &attr, kPOVAttrib_FileName) == 0)
     {
      l = 0;
      if(POVMSAttr_Size(&attr, &l) == 0)
      {
       if(l < 256)
       {
        if(POVMSAttr_Get(&attr, kPOVMSType_CString,
                             (void *)(&fname[1]), &l) == 0)
        {
         fname[0] = l - 1;
         if(FSMakeFSSpec(0, 0, fname, &file) != noErr)
          fname[0] = 0;
        }
       }
      }
      (void)POVMSAttr_Delete(&attr);
     }
     if(POVMSObject_Get(msg, &attr, kPOVAttrib_Line) == 0)
     {
      l = sizeof(int);
      ret = POVMSAttr_Get(&attr, kPOVMSType_Int, (void *)(&line), &l);
      (void)POVMSAttr_Delete(&attr);
     }
     if(ret == 0)
     {
      if(fname[0] == 0)
       (dynamic_cast<POVRayMac *>(gApplication))->messageWindow->
                     AddMessage(kStatusError, h, NULL, 0);
      else
       (dynamic_cast<POVRayMac *>(gApplication))->messageWindow->
                     AddMessage(kStatusError, h, &file, line);
     }
     break;
    case kPOVMsgIdent_Warning:
     ret = POVMSObject_Get(msg, &attr, kPOVAttrib_EnglishText);
     if(ret == 0)
      ret = POVMSAttr_Size(&attr, &l);
     if(ret == 0)
     {
      h = NewHandle(l);
      if(h == NULL)
       ret = -2;
     }
     if(ret == 0)
     {
      HLock(h);
      ret = POVMSAttr_Get(&attr, kPOVMSType_CString, (void *)(*h), &l);
      HUnlock(h);
     }
     if(ret == 0)
      (void)POVMSAttr_Delete(&attr);
     if(POVMSObject_Get(msg, &attr, kPOVAttrib_FileName) == 0)
     {
      l = 0;
      if(POVMSAttr_Size(&attr, &l) == 0)
      {
       if(l < 256)
       {
        if(POVMSAttr_Get(&attr, kPOVMSType_CString,
                             (void *)(&fname[1]), &l) == 0)
        {
         fname[0] = l - 1;
         if(FSMakeFSSpec(0, 0, fname, &file) != noErr)
          fname[0] = 0;
        }
       }
      }
      (void)POVMSAttr_Delete(&attr);
     }
     if(POVMSObject_Get(msg, &attr, kPOVAttrib_Line) == 0)
     {
      l = sizeof(int);
      ret = POVMSAttr_Get(&attr, kPOVMSType_Int, (void *)(&line), &l);
      (void)POVMSAttr_Delete(&attr);
     }
     if(ret == 0)
     {
      if(fname[0] == 0)
       (dynamic_cast<POVRayMac *>(gApplication))->messageWindow->
                     AddMessage(kStatusWarning, h, NULL, 0);
      else
       (dynamic_cast<POVRayMac *>(gApplication))->messageWindow->
                     AddMessage(kStatusWarning, h, &file, line);
     }
     break;
    case kPOVMsgIdent_Debug:
     ret = POVMSObject_Get(msg, &attr, kPOVAttrib_EnglishText);
     if(ret == 0)
      ret = POVMSAttr_Size(&attr, &l);
     if(ret == 0)
     {
      h = NewHandle(l);
      if(h == NULL)
       ret = -2;
     }
     if(ret == 0)
     {
      HLock(h);
      ret = POVMSAttr_Get(&attr, kPOVMSType_CString, (void *)(*h), &l);
      HUnlock(h);
     }
     if(ret == 0)
      (void)POVMSAttr_Delete(&attr);
     if(ret == 0)
      (dynamic_cast<POVRayMac *>(gApplication))->messageWindow->
                    AddMessage(kStatusDebug, h, NULL, 0);
     break;
    default:
     h = NewHandle(5);
     if(h == NULL)
      ret = -2;
     if(ret == 0)
     {
      HLock(h);
      *((int *)(*h)) = hid;
      (*h)[4] = 0;
      HUnlock(h);
      (dynamic_cast<POVRayMac *>(gApplication))->messageWindow->
                    AddMessage(kStatusDebug, h, NULL, 0);
     }
     break;
   }
  }

  return ret;
}

 > PS I think the pre-beta is going very well. I'm pleased with the number of
 > bugs we've quashed, and also the amount of contributed work that's coming
 > in (e.g. the scenes, includes, and the icons for the windows version).

I agree.  A lot of bugs have been found, and with a bit of luck we can
have a public beta in the foreseeable future.

        Thorsten

-------- Original Message --------
Subject: 	Re: Possible memleak in POVMS ?
Date: 	Wed, 17 Mar 2004 19:40:01 +0100
From: 	Thorsten Froehlich
Newsgroups: 	private.povray.programming
References: 	<40588369@news.povray.org>

In article <40588369@news.povray.org> , Nicolas Calimet wrote:

 >         So I went to look at the core code, and noticed that only
 > base/povms.cpp still uses direct calls to malloc and friends, as
 > denoted in a comment near the top of the file where the POVMS_Sys_*
 > macros are declared.  If there is a leak here, it won't be reported
 > as in the rest of the code.

Yes, POVMS cannot use the POV_xxx memory allocation functions because POVMS
is used for error output inside the memory allocation functions.  Thus, if
memory allocation would fail inside POVMS it would trigger a POVMS message
to be generated, which would try to allocate memory, fail to allocate it and
trigger a POVMS message to be generated, and so on.

This is why there are the macros.  They allow POVMS memory allocation to be
replaced by something system specific that works on a lower level than
POV_xxx memory allocation.  The Mac version makes use of this to overload
the POVMS memory allocation with a special multithreadsafe allocator (so one
can link the core code against a non-multithreadsafe allocator, which tends
to be a bit faster).

In addition to this, the Mac also overloads the generic POV_xxx memory
allocation functions to provide a nice way to fail in out of memory
conditions by having a special safety buffer (128 KB) that is released when
POV-Ray runs out of memory.  This free memory allows the GUI (and POVMS)
enough air to run important tasks such as displaying an error message before
POV_xxx memory allocations are freed.

Consequently, the Mac memory allocation is much different from the generic
memory allocation.  And the Mac version also uses slightly different (older)
handlers for POVMS, which were back during the 3.5 development tested for
memory leaks.  It may well be that the 3.6 default handlers or other changes
in 3.6 do indeed cause memory leaks in POVMS (i.e. messages are not freed).
I do have the old code to debug POVMS memory allocation somewhere.  If I can
get it to compile again, I will either post it or submit it (if that makes
sense - this depends on the stability of the memory debugging code for
POVMS) such that you can then debug POVMS as it behaves on your platform.

I will make getting this code working a priority, so hopefully I will have
it ready for you later this week(end).

Regarding the slowdown, Chris and I observed similar patterns on Mac and
Windows, but we were able to at least obscure it by making parsing faster.
Still, we are not sure parsing was the real cause of the slowdown.  There
was simply not enough time to investigate this closer for beta 2.

     Thorsten

[gaprie] Modify source code of program POVRAY [4346 days 1 hour and 37 minutes ago]

Wed, 28 May 2014 01:00:01 GMT

Hello everyone,
I want to ask How we can open the source code of program POVRay?
If we can do it, we can see the flow proses rendering in POVRay and we can
modify that such we can add some coding (like MPI maybe) for get paralel
rendering program with POVRay.
Sorry, I am new in POVRay.

Regards,
Galih Pribadi

[gaprie] merge TGA file in POVRay [4356 days 20 hours and 52 minutes ago]

Sat, 17 May 2014 05:45:00 GMT

Hello everyone,

I would like to ask, if I have 2 pieces of Povray rendering result of TGA images
and want to merge them into one whole image. Anyone ever tried?

For example, the object "pawns.pov" which has a pixel size of 400 (w) x300 (h),
I render into 2 parts:

"pawns_top.tga" (rendered from rows 1-150) with the command:
#povray +W400 +H300 +SR1 +ER150 FT +Opawns_top pawns.pov
"pawns_bottom.tga" (rendered from lines 151-300) with the command:
#povray +W400 +H300 +SR151 +ER300 +FT +Opawns_bottom pawns.pov

And I wish I merge into "pawns.tga"

I have tried with the following command from the link
"http://povray.tashcorp.net/tutorials/qd_multicpu_render/"
# cp pawns_top.tga pawns.tga
# tail-c +19 pawns_bottom.tga >> pawns.tga

No error message,. But the merged image only contains images of paws_top.

Thank you for all your help ^ _ ^.

Regards,
Galih

[Martin Samuelsson] Re: MPI with povray [4486 days 20 hours and 37 minutes ago]

Tue, 7 Jan 2014 06:00:00 GMT

"koppi" <jak### [at] gmailcom> wrote:
> There is also httpov

And from time to time, I manage to update it. Yesterday, I published 0.9 of the
server, which makes it possible to render just parts of an animation, instead of
starting all over if you just want to tweak something in the middle.

Regards,
/Martin

[koppi] Re: MPI with povray [4914 days 10 hours and 27 minutes ago]

Mon, 5 Nov 2012 16:10:01 GMT

There is also httpov -- http://columbiegg.com/httpov which works very nicely for
me (using the google computing services and amazon aws - a bit expensive!).

PVMPOV, similar to MPIPOV -- http://pvmpov.sourceforge.net isn't really
maintained any more for the last 11 years or so (but it still compiles nicely
with the recent gcc versions)..

Hth, Jakob

[Jaime Vives Piqueres] Re: call megapov in Matlab, but where is the pic... [5030 days 17 hours and 37 minutes ago]

Thu, 12 Jul 2012 09:00:45 GMT

On 12/07/12 10:36, AENZO wrote:
> Hi Jamie, I fixed the prob,
>
> Just need define the format of the pic,

   Ah... I was going to suggest you to try other format next.

> thank you sooo much, and sorry about the
> disturbing

   Don't worry, that's what the newsgroups are for...

   Regards,

--
Jaime

[AENZO] Re: call megapov in Matlab, but where is the pic... [5030 days 17 hours and 57 minutes ago]

Thu, 12 Jul 2012 08:40:01 GMT

Hi Jamie, I fixed the prob,

Just need define the format of the pic,
thank you sooo much, and sorry about the
disturbing

Regards

Aenzo

[Jaime Vives Piqueres] Re: call megapov in Matlab, but where is the pic... [5030 days 17 hours and 58 minutes ago]

Thu, 12 Jul 2012 08:39:45 GMT

On 12/07/12 10:07, AENZO wrote:
> I redo the coding and did like you said, and the mega generate the
> pic but i can not open it, and the message like this:

I overlooked this line on the messages from your first post:

> File Init Error: Cannot open output file.

...so, it looks like you don't have permission to write on that folder?

> 0:00:00 Displaying (null) (null) (null) (null) (null) (null)
> ......... (null)                               ..   ........ ...
> (null)                             .. ...................
> (null)                          .. .... ................
> (null) .... ............. ......                            (null) .
> .. .......... .......... 0:00:01 Displaying line 292 of 600(null)
> .... ... ... ..  ..........                         (null)
> ... . ... ..........                         (null)
> . .. ... .                         (null)
> ..... . .....                          (null)
> . . ..             .                             (null) .
> (null) (null) (null) (null) (null) (null) (null)

   That looks like the alternative preview used when there is no graphic
support compiled on the binary... maybe you're using the console version
of MegaPOV? (I don't know if it was compiled with graphic display support)

   Regards,

--
Jaime

[AENZO] Re: call megapov in Matlab, but where is the pic... [5030 days 18 hours and 2 minutes ago]

Thu, 12 Jul 2012 08:35:01 GMT

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Enzo, the answer to your question is contained on your post two times!>
>
> > !"C:\Program Files\POV-Ray for Windows v3.6\bin\MEGAPOV"
> > +I"E:\Dropbox\POV ray\2012.07.10\Tree Model_only
> > Leafs_no_shadow08.pov" +O"E:\Dropbox\POV ray\2012.07.10\a.bmp"
> > +L"C:\Program Files\POV-Ray for Windows v3.6\include" +W800 +H600
> >
>
>    Here the command line contains the output file name, explicitly set to
> "E:\Dropbox\POV ray\2012.07.10\a.bmp".
>
> > Output Options Image resolution 800 by 600 (rows 1 to 600, columns 1
> > to 800). Output file: E:\Dropbox\POV ray\2012.07.10/\Dropbox\POV
> > ray\2012.07.10\a.bmp,
>
>    And here again, the renderer tells you about it on the messages window...
>
> > I thought that might the problem "Graphic display......Off ", but how
> > can i turn on it?
>
>    No, that was not the problem, but anyhow you can turn display on
> adding +d on your command line.
>
>    Regards,
>
> --
> Jaime

Hi Jaime

I used new code like this :

 !"C:\Program Files\POV-Ray for Windows v3.6\bin\MEGAPOV"
 +I"E:\Dropbox\POV ray\2012.07.10\Tree Model_only Leafs_no_shadow07.pov"
+O"\Tree Model_only Leafs_no_shadow07.bmp"
+L"C:\Program Files\POV-Ray for Windows v3.6\include"
+W800 +H600 +D

and it generated the pic , but could not be displayed, would you see this for
me?

thank you

Regards,

Aenzo

[AENZO] Re: call megapov in Matlab, but where is the pic... [5030 days 18 hours and 7 minutes ago]

Thu, 12 Jul 2012 08:30:01 GMT

Hi Jaime,

I have got the answer about "null", it seems the megapov rendered the pic in
binary dots,  like the message shows, but the pic still could not be displayed,
i still working on this

ps, the new command is this:

 !"C:\Program Files\POV-Ray for Windows v3.6\bin\MEGAPOV"
 +I"E:\Dropbox\POV ray\2012.07.10\Tree Model_only Leafs_no_shadow07.pov"
 +O"Tree Model_only Leafs_no_shadow07.bmp"
 +L"C:\Program Files\POV-Ray for Windows v3.6\include"
 +W800 +H600 +D

Aenzo

regards

[AENZO] Re: call megapov in Matlab, but where is the pic... [5030 days 18 hours and 27 minutes ago]

Thu, 12 Jul 2012 08:10:01 GMT

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Enzo, the answer to your question is contained on your post two times!>
>
> > !"C:\Program Files\POV-Ray for Windows v3.6\bin\MEGAPOV"
> > +I"E:\Dropbox\POV ray\2012.07.10\Tree Model_only
> > Leafs_no_shadow08.pov" +O"E:\Dropbox\POV ray\2012.07.10\a.bmp"
> > +L"C:\Program Files\POV-Ray for Windows v3.6\include" +W800 +H600
> >
>
>    Here the command line contains the output file name, explicitly set to
> "E:\Dropbox\POV ray\2012.07.10\a.bmp".
>
> > Output Options Image resolution 800 by 600 (rows 1 to 600, columns 1
> > to 800). Output file: E:\Dropbox\POV ray\2012.07.10/\Dropbox\POV
> > ray\2012.07.10\a.bmp,
>
>    And here again, the renderer tells you about it on the messages window...
>
> > I thought that might the problem "Graphic display......Off ", but how
> > can i turn on it?
>
>    No, that was not the problem, but anyhow you can turn display on
> adding +d on your command line.
>
>    Regards,
>
> --
> Jaime

Hi Jaime,

I redo the coding and did like you said, and the mega generate the pic
but i can not open it, and the message like this:

Support libraries used by POV-Ray:
  ZLib 1.2.3, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
  LibPNG 1.2.8, Copyright 1998-2002 Glenn Randers-Pehrson
  LibJPEG 6b, Copyright 1998 Thomas G. Lane
  LibTIFF 3.6.1, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Redirecting Options
  All Streams to console..........On
  Debug Stream to console.........On
  Fatal Stream to console.........On
  Render Stream to console........On
  Statistics Stream to console....On
  Warning Stream to console.......On
Parsing Options
  Input file: E:\Dropbox\POV ray\2012.07.10\Tree Model_only Leafs_no_shadow08.po
v (compatible to version 3.61)
  Remove bounds........On
  Split unions.........Off
  Library paths:
    C:\Program Files\POV-Ray for Windows v3.6\include
Output Options
  Image resolution 800 by 600 (rows 1 to 600, columns 1 to 800).
  Output file: E:\Dropbox\POV ray\2012.07.10/Tree Model_only Leafs_no_shadow08.b
mp, 24 bpp Targa
  Graphic display......On  (gamma: 2.2)
  Mosaic preview.......Off
  CPU usage histogram..Off
  Continued trace......Off
Tracing Options
  Quality:  9
  Bounding boxes.......On   Bounding threshold: 25
  Light Buffer.........On
  Vista Buffer.........On   Draw Vista Buffer....Off
  Antialiasing.........Off
  Clock value:    0.000  (Animation off)

  0:00:00 Parsing
  0:00:01 Parsing 297K tokens
  0:00:02 Parsing 2405K tokens
  0:00:03 Parsing 4486K tokens
  0:00:04 Parsing 6267K tokens
  0:00:05 Parsing 8250K tokens
  0:00:05 Creating bounding slabs
  0:00:05 Creating vista buffer(null)
  0:00:05 Creating light buffers
  0:00:05 Creating light buffers 9232K tokens
Scene Statistics
  Finite objects:         8305
  Infinite objects:          0
  Light sources:             0
  Total:                  8305

  0:00:00 Displaying
                (null)
                  (null)
                    (null)
                      (null)
                        (null)
                          (null)                                  .........
                            (null)                               ..   ........
...                              (null)                             ..
...................                           (null)                          ..
.... ................                           (null)
.... ............. ......                            (null)
  . .. .......... ..........
  0:00:01 Displaying line 292 of 600(null)                        .... ... ...
..  ..........                         (null)                       ... . ...
     ..........                         (null)                             .
         .. ... .                         (null)                          .....
           . .....                          (null)                           . .
 ..             .                             (null)
              .                                 (null)
                                                  (null)
                                                    (null)
                                                      (null)
                                                        (null)
                                                          (null)
                                                            (null)
  0:00:01 Postprocessing Phase 0, line 0
  0:00:01 Done Tracing
Render Statistics
Image Resolution 800 x 600
----------------------------------------------------------------------------
Pixels:           480000   Samples:          480000   Smpls/Pxl: 1.00
Rays:             480000   Saved:                 0   Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Disc                            185440           57549     31.03
Bounding Box                   1203270          646763     53.75
Vista Buffer                   5352939         3105899     58.02
----------------------------------------------------------------------------
Calls to Noise:                   0   Calls to DNoise:              10
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Smallest Alloc:                  18 bytes
Largest  Alloc:               94256 bytes
Peak memory used:           8009158 bytes

  0:00:01 Reclaiming memory
Total Scene Processing Times
  Parse Time:    0 hours  0 minutes  5 seconds (5 seconds)
  Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
  Cloth Time:    0 hours  0 minutes  0 seconds (0 seconds)
  Mechsim Time:  0 hours  0 minutes  0 seconds (0 seconds)
  Render Time:   0 hours  0 minutes  1 seconds (1 seconds)
  Postpr. Time:  0 hours  0 minutes  0 seconds (0 seconds)
  Total Time:    0 hours  0 minutes  6 seconds (6 seconds)


I dont understand what the "null" is, would you See this for me?

Thank you


Aenzo

best regards!

[Jaime Vives Piqueres] Re: call megapov in Matlab, but where is the pic... [5030 days 19 hours and 1 minute ago]

Thu, 12 Jul 2012 07:36:45 GMT

Enzo, the answer to your question is contained on your post two times!>

> !"C:\Program Files\POV-Ray for Windows v3.6\bin\MEGAPOV"
> +I"E:\Dropbox\POV ray\2012.07.10\Tree Model_only
> Leafs_no_shadow08.pov" +O"E:\Dropbox\POV ray\2012.07.10\a.bmp"
> +L"C:\Program Files\POV-Ray for Windows v3.6\include" +W800 +H600
>

   Here the command line contains the output file name, explicitly set to
"E:\Dropbox\POV ray\2012.07.10\a.bmp".

> Output Options Image resolution 800 by 600 (rows 1 to 600, columns 1
> to 800). Output file: E:\Dropbox\POV ray\2012.07.10/\Dropbox\POV
> ray\2012.07.10\a.bmp,

   And here again, the renderer tells you about it on the messages window...

> I thought that might the problem "Graphic display......Off ", but how
> can i turn on it?

   No, that was not the problem, but anyhow you can turn display on
adding +d on your command line.

   Regards,

--
Jaime

[AENZO] call megapov in Matlab, but where is the pic gen... [5030 days 19 hours and 17 minutes ago]

Thu, 12 Jul 2012 07:20:01 GMT

Hi everybuddy, i run command in MATLAB like this

!"C:\Program Files\POV-Ray for Windows v3.6\bin\MEGAPOV" +I"E:\Dropbox\POV
ray\2012.07.10\Tree Model_only Leafs_no_shadow08.pov" +O"E:\Dropbox\POV
ray\2012.07.10\a.bmp" +L"C:\Program Files\POV-Ray for Windows v3.6\include"
+W800 +H600

and it worked and the messages like :

Microsoft Windows XP

Redirecting Options
  All Streams to console..........On
  Debug Stream to console.........On
  Fatal Stream to console.........On
  Render Stream to console........On
  Statistics Stream to console....On
  Warning Stream to console.......On
Parsing Options
  Input file: E:\Dropbox\POV ray\2012.07.10\Tree Model_only Leafs_no_shadow08.po
v (compatible to version 3.61)
  Remove bounds........On
  Split unions.........Off
  Library paths:
    C:\Program Files\POV-Ray for Windows v3.6\include
Output Options
  Image resolution 800 by 600 (rows 1 to 600, columns 1 to 800).
  Output file: E:\Dropbox\POV ray\2012.07.10/\Dropbox\POV ray\2012.07.10\a.bmp,
 24 bpp Targa
  Graphic display......Off
  Mosaic preview.......Off
  CPU usage histogram..Off
  Continued trace......Off
Tracing Options
  Quality:  9
  Bounding boxes.......On   Bounding threshold: 25
  Light Buffer.........On
  Vista Buffer.........On   Draw Vista Buffer....Off
  Antialiasing.........Off
  Clock value:    0.000  (Animation off)

  0:00:00 Parsing
  0:00:01 Parsing 1943K tokens
  0:00:02 Parsing 3999K tokens
  0:00:03 Parsing 5884K tokens
  0:00:04 Parsing 8025K tokens
  0:00:04 Creating bounding slabs
  0:00:04 Creating vista buffer
  0:00:04 Creating light buffers
  0:00:04 Creating light buffers 9232K tokens
Scene Statistics
  Finite objects:         8305
  Infinite objects:          0
  Light sources:             0
  Total:                  8305
File Init Error: Cannot open output file.

  0:00:00 Reclaiming memory
Total Scene Processing Times
  Parse Time:    0 hours  0 minutes  4 seconds (4 seconds)
  Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
  Cloth Time:    0 hours  0 minutes  0 seconds (0 seconds)
  Mechsim Time:  0 hours  0 minutes  0 seconds (0 seconds)
  Render Time:   0 hours  0 minutes  0 seconds (0 seconds)
  Postpr. Time:  0 hours  0 minutes  0 seconds (0 seconds)
  Total Time:    0 hours  0 minutes  4 seconds (4 seconds)

I thought that might the problem "Graphic display......Off ", but how can i turn
on it?  it would be thankful, if you could help me , thx a million!!!

[trp] Re: Call pov-render to picturebox [5587 days 11 hours and 32 minutes ago]

Sun, 2 Jan 2011 15:05:01 GMT

This does seem to come up every so often. There should be a FAQ. (Maybe there
is. I'll look after I post this.) Anyway, here are a couple of earlier
references.

http://news.povray.org/web.4c0165e33f4c95c6bba08f230%40news.povray.org

http://news.povray.org/web.4c5df3ad7c1e70dfbba08f230%40news.povray.org

Good luck.

[[GDS|Entropy]] Re: Call pov-render to picturebox [5587 days 20 hours and 55 minutes ago]

Sun, 2 Jan 2011 05:42:34 GMT

On Sat, 01 Jan 2011 22:23:18 -0500, StephenS <nomail@nomail> wrote:

> clipka <ano### [at] anonymousorg> wrote:
>> Am 02.01.2011 04:03, schrieb [GDS|Entropy]:
>> > Hello,
>> >
>> > How do you call povray to render in a PictureBox from c# in the way  
>> that
>> > Moray does?
>> >
>> ...
>> >
>> > Or is there any api documentation (or code sample in any language)
>> > someone can point me to?
>>
>> Yes: The Moray code :-P
>>
>> There is a plug-in API for POV-Ray, which allows you to plug-in other
>> software (like Moray) into POV-Ray. There must be some kind of
>> documentation /somewhere/ on the web pages.
>
> You may also want to look for 'GUI Extension'.

Very good then..I will look for that in Google too.

Failing my finding anything I can use there, I will just initiate a new  
command-line process and pass the requisite variables, then load the  
output to the picturebox...though that is a horribly kludgey solution. :|

> Stephen S

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

[[GDS|Entropy]] Re: Call pov-render to picturebox [5587 days 20 hours and 59 minutes ago]

Sun, 2 Jan 2011 05:38:25 GMT

On Sat, 01 Jan 2011 22:10:34 -0500, clipka <ano### [at] anonymousorg> wrote:

> Am 02.01.2011 04:03, schrieb [GDS|Entropy]:
>> Hello,
>>
>> How do you call povray to render in a PictureBox from c# in the way that
>> Moray does?
>>
> ...
>>
>> Or is there any api documentation (or code sample in any language)
>> someone can point me to?
>
> Yes: The Moray code :-P

Oh...so that is open source now? Well...damn..I had no idea and will have  
to look around for the source repository then..wherever that is..

> There is a plug-in API for POV-Ray, which allows you to plug-in other  
> software (like Moray) into POV-Ray. There must be some kind of  
> documentation /somewhere/ on the web pages.

Ok..I'll look for that then. Is that on the main pov site?
Keep in mind I do not have just all of the time in the world to look this  
stuff up..I am a very busy person..so please forgive me if I ask questions  
that may be answered "easily" if I were to have more of that precious  
resource.. ;)

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

[StephenS] Re: Call pov-render to picturebox [5587 days 23 hours and 12 minutes ago]

Sun, 2 Jan 2011 03:25:01 GMT

clipka <ano### [at] anonymousorg> wrote:
> Am 02.01.2011 04:03, schrieb [GDS|Entropy]:
> > Hello,
> >
> > How do you call povray to render in a PictureBox from c# in the way that
> > Moray does?
> >
> ...
> >
> > Or is there any api documentation (or code sample in any language)
> > someone can point me to?
>
> Yes: The Moray code :-P
>
> There is a plug-in API for POV-Ray, which allows you to plug-in other
> software (like Moray) into POV-Ray. There must be some kind of
> documentation /somewhere/ on the web pages.

You may also want to look for 'GUI Extension'.

Stephen S

[clipka] Re: Call pov-render to picturebox [5587 days 23 hours and 26 minutes ago]

Sun, 2 Jan 2011 03:10:57 GMT

Am 02.01.2011 04:03, schrieb [GDS|Entropy]:
> Hello,
>
> How do you call povray to render in a PictureBox from c# in the way that
> Moray does?
>
...
>
> Or is there any api documentation (or code sample in any language)
> someone can point me to?

Yes: The Moray code :-P

There is a plug-in API for POV-Ray, which allows you to plug-in other 
software (like Moray) into POV-Ray. There must be some kind of 
documentation /somewhere/ on the web pages.

[[GDS|Entropy]] Call pov-render to picturebox [5587 days 23 hours and 34 minutes ago]

Sun, 2 Jan 2011 03:03:39 GMT

Hello,

How do you call povray to render in a PictureBox from c# in the way that  
Moray does?

Is this a matter of something like this (Then loading the output image  
into the PictureBox):
Process myProc = new Process();
myProc.StartInfo.Filename = "dir\abc.exe";
myProc.StartInfo.Arguments = "file1, file2, file3";
myProc.Start();

Or is there any api documentation (or code sample in any language) someone  
can point me to?

Thanks!

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

[clipka] Re: Radiosity in 3.6 vs. 3.7 [6324 days 20 hours and 37 minutes ago]

Fri, 26 Dec 2008 06:00:00 GMT

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Apologies in advance if I'm confused about something: When *loading* the rad
> data, did you use the accepted 'witchcraft' thing of setting both
> pretrace_start and pretrace_end to 1 (along with always_sample off)? Or did you
> run the loaded data with the exact same rad settings that you saved it with? I'm
> curious if either one or the other made any visual difference (that is, any
> difference from single-pass radiosity.)

Back then I wasn't using witchcraft yet, just ordinary magic - so of course I
used really identical settings.

[Kenneth] Re: Radiosity in 3.6 vs. 3.7 [6324 days 22 hours and 2 minutes ago]

Fri, 26 Dec 2008 04:35:01 GMT

"clipka" <nomail@nomail> wrote:
> This is a section of a scene using almost exclusively radiosity-based lighting,
> as rendered by:
>
> (a) POV-ray 3.6.1c using fairly high quality radiosity settings, and a separate
> pretrace render with save_file/load_file (i.e. doing pretrace and final render
> in separate runs of POV-ray) which I found to smoothen out quite a lot of
> artifacts in the picture. The main shot was taken twice the resolution shown
> here.

Apologies in advance if I'm confused about something: When *loading* the rad
data, did you use the accepted 'witchcraft' thing of setting both
pretrace_start and pretrace_end to 1 (along with always_sample off)? Or did you
run the loaded data with the exact same rad settings that you saved it with? I'm
curious if either one or the other made any visual difference (that is, any
difference from single-pass radiosity.)

BTW, *funny* cat image!

Ken W.

[clipka] Re: Radiosity in 3.6 vs. 3.7 [6325 days 1 hour and 2 minutes ago]

Fri, 26 Dec 2008 01:35:01 GMT

"nemesis" <nam### [at] gmailcom> wrote:
> Are you sure you used the same settings for both?

Definitely.

> With my own tests it's the contrary:  a single radiosity pass always gives the
> best results...

Interestingly, that scene has been the only one so far that really worked with
the save & reload approach.

> > An interesting side note though: Did you know that you actually don't get the
> > specified count for all your samples? Instead, the effective count decreases
> > drastically with trace depth. In fact all your quality settings do.
>
> Hmm, I expected it to be an upper limit, yes.  The trace you're talking about is
> from the pretrace step or is the "bounces" number?

I'm taking about the "bounces" here.

[nemesis] Re: Radiosity in 3.6 vs. 3.7 [6325 days 5 hours and 12 minutes ago]

Thu, 25 Dec 2008 21:25:01 GMT

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > "clipka" <nomail@nomail> wrote:
> > > It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> > > that for some reasons it gives exceptionally bad results on the left side of
> > > the pedestal's top.
> >
> > What bad results?  You're talking about (a), right?
>
> No, to me (a) looks more realistic than all the others - I'm talking about (b).

Ok.  (a) looked the best, obviously, so I thought it was strange of you to be
dissing it.

> > > This also shows that 3.6.1 radiosity is far from perfect
> >
> > Why?
>
> 'cuz it gives you significantly different results depending on whether you save
> and later re-load the whole smash. Taking some more samples should reduce
> artifacts, but not change anything dramatically.

Are you sure you used the same settings for both?  If you don't write down
concrete values, default values are used and if one scene sets a value for an
attribute and the other doesn't, the default value may indeed have great
impact.

With my own tests it's the contrary:  a single radiosity pass always gives the
best results...

> An interesting side note though: Did you know that you actually don't get the
> specified count for all your samples? Instead, the effective count decreases
> drastically with trace depth. In fact all your quality settings do.

Hmm, I expected it to be an upper limit, yes.  The trace you're talking about is
from the pretrace step or is the "bounces" number?

[clipka] Re: Radiosity in 3.6 vs. 3.7 [6325 days 10 hours and 42 minutes ago]

Thu, 25 Dec 2008 15:55:00 GMT

"nemesis" <nam### [at] gmailcom> wrote:
> "clipka" <nomail@nomail> wrote:
> > It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> > that for some reasons it gives exceptionally bad results on the left side of
> > the pedestal's top.
>
> What bad results?  You're talking about (a), right?

No, to me (a) looks more realistic than all the others - I'm talking about (b).
And from the process of how it was generated, I must assume that it took more
samples than the others.

> > This also shows that 3.6.1 radiosity is far from perfect
>
> Why?

'cuz it gives you significantly different results depending on whether you save
and later re-load the whole smash. Taking some more samples should reduce
artifacts, but not change anything dramatically.

> And, hey, while you're messing around with it, how about getting
> radiosity "count" limit way up? ;)

Not so high on my agenda. It's a bit "tricksy" anyway: It's not like POV-ray
would just shoot so many random rays - in that case there wouldn't be any
reason for the "hard deck" of 1600 samples. Instead, POV-ray picks the first N
rays from a hard-coded sequence of 1600 sampling directions.

MegaPOV has a mechanism to supply your own sampling directions, and thereby
overcome that limitation. But I'd rather go for figuring out how the original
sampling directions were chosen, and implement an algorithm that re-computes
the very same sequence when POV initializes the radiosity code. Or a larger
one.

Using truly random directions is not an option, because producing (pseudo-)
random numbers is a comparatively costly thing, converting them to suitably
distributed directions requires a bit of trigonometric functions (highly
costly!), and would actually need a higher count to get the same quality.

An interesting side note though: Did you know that you actually don't get the
specified count for all your samples? Instead, the effective count decreases
drastically with trace depth. In fact all your quality settings do.

[nemesis] Re: Radiosity in 3.6 vs. 3.7 [6325 days 12 hours and 12 minutes ago]

Thu, 25 Dec 2008 14:25:00 GMT

"clipka" <nomail@nomail> wrote:
> It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> that for some reasons it gives exceptionally bad results on the left side of
> the pedestal's top.

What bad results?  You're talking about (a), right?

> (c) and (d) aren't too much apart - but for some reasons I don't yet understand,
> (d) renders a lot faster (factor 3!!!), so it looks like I did *something*
> right.

That's great!

> This also shows that 3.6.1 radiosity is far from perfect

Why?  And, hey, while you're messing around with it, how about getting radiosity
"count" limit way up? ;)

[clipka] Re: Radiosity in 3.6 vs. 3.7 [6325 days 18 hours and 47 minutes ago]

Thu, 25 Dec 2008 07:50:00 GMT

"SharkD" <nomail@nomail> wrote:
> Rats! If I'd known that the quality of the radiosity in beta 29 were so poor I
> would have rendered my 56 frame scene in 3.6.1. At least beta 29 is much
> faster...
>
> -Mike

I has good news for you...

[SharkD] Re: Radiosity in 3.6 vs. 3.7 [6325 days 19 hours and 42 minutes ago]

Thu, 25 Dec 2008 06:55:01 GMT

Rats! If I'd known that the quality of the radiosity in beta 29 were so poor I
would have rendered my 56 frame scene in 3.6.1. At least beta 29 is much
faster...

-Mike

[clipka] Radiosity in 3.6 vs. 3.7 [6326 days 1 hour and 12 minutes ago]

Thu, 25 Dec 2008 01:25:00 GMT

This is a section of a scene using almost exclusively radiosity-based lighting,
as rendered by:

(a) POV-ray 3.6.1c using fairly high quality radiosity settings, and a separate
pretrace render with save_file/load_file (i.e. doing pretrace and final render
in separate runs of POV-ray) which I found to smoothen out quite a lot of
artifacts in the picture. The main shot was taken twice the resolution shown
here.

(b) POV-ray 3.6.1c using exactly(!) the same settings as (a), but without using
the save_file/load_file (i.e. pretrace and final render were done in the same
run) and the resolution you see here.

(c) POV-ray 3.7.0.beta.29, using exactly same setup as for (b).

(d) a modified version of POV-ray 3.7.0.beta.29 (my current status for the
radiosity bugfixing work).

The bottom row shows the (somewhat enhanced) difference between the respective
shot and (a) (which I'd expect to come closest to reality).

It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
that for some reasons it gives exceptionally bad results on the left side of
the pedestal's top.

(c) and (d) aren't too much apart - but for some reasons I don't yet understand,
(d) renders a lot faster (factor 3!!!), so it looks like I did *something*
right.

This also shows that 3.6.1 radiosity is far from perfect, and it's probably not
a good idea to take it as a reference after all for the 3.7 development.

[alphaQuad] glib vc98 for SVG reader [6409 days 7 hours and 22 minutes ago]

Thu, 2 Oct 2008 19:15:00 GMT

I bet Nicolas knows this stuff.

Trying to see how far I can get with Inkscape SVG code. First off just trying to
include <glib.h> fails. Is this a VC6 issue? or can I fix it. Totally lost here.

I suppose mingw would be better approach? no gui ;(

"use of class template requires template argument list"

thats like asking a blind man to hand you the red one,
in my case.

[Luc H ] Re: MPI with povray [6492 days 16 hours and 38 minutes ago]

Fri, 11 Jul 2008 09:59:18 GMT

Hello

MPI is a way to render faster but not the only one. It's fine when you 
already have an MPI farm.

If it's something from scratch, maybe you should look at 
http://www.dynebolic.org/ : the cluster way.
OpenMosix is another cluster manager, but not maintened anymore. 
http://openmosix.sourceforge.net/

By the way, "recent" achievements on P2P networks and SMP makes me wondering 
about a P2P rewrite for POV.
Just connect your PCs, let them talk and work, and get everything faster... 
For POV 5 ?

Regards,
 Luc H.

"horry" <nomail@nomail> a écrit dans le message de news: 
web.4815c45d234dc46ce1b6a22d0@news.povray.org...
> Hi all!
> I am looking for an implemetation of povray that could be used with mpi, 
> in
> order to make parallel rendering in our cluster.
> I have found an implementation called mpi-povray, but only works with the
> version 3.1g of povray, and we need work with a newer version.
>
> Thank you
> Omar
>

[felipecastillof] Re: MPI patch for povray 3.5c [6519 days 3 hours and 17 minutes ago]

Sat, 14 Jun 2008 23:20:01 GMT

Matthias <mat### [at] webde> wrote:
> Hi folks,
>
> based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> Irix.
> It works with the new automake/autoconf system of povray 3.5, so just
> unpack the archive to your povray directory and run './configure',
> 'make' and 'make install', nothing new for you guys ;-)
> It has statistics, options and other stuff, so try it out!!
> Requirements are povray3.5c and LAM/MPI 6.5.x
> What do you think about it??
> If you like it, I hope it can be added to the tools section on the
> povray homepage...
>
> Matthias



HI Matthias and Everyone!!
Sorry for my bad english, pero i need the patch for povray and lam, the patch
it's seems corrupted, and i can't uncompress this. Can you fix this please?, o
send me to mi mail??, fel### [at] gmailcom.
Bye and thank you!!!

[horry] Re: MPI with povray [6565 days 17 hours and 32 minutes ago]

Tue, 29 Apr 2008 09:05:00 GMT

"Aydan" <hes### [at] hendrik-sachsenet> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > Aydan <hes### [at] hendrik-sachsenet> wrote:
> > > Read the beta pages: 3.7 has MP capability
> >   3.7 has SMP capability, but it doesn't yet have clustering capabilities.
> ooops, must have overread the cluster part.
>
> Aydan

Thank you for your answers,

I know that the new version 3.7 of povray have SMP, but I need work with all the
nodes of my cluster, not only with one of them.
I have found others alternatives to MPI with povray that support the version
3.5, but I want to communicate our computers by the faster way, with OpenMPI.

Thank you,
Omar

[Aydan] Re: MPI with povray [6566 days 9 hours and 32 minutes ago]

Mon, 28 Apr 2008 17:05:00 GMT

Warp <war### [at] tagpovrayorg> wrote:
> Aydan <hes### [at] hendrik-sachsenet> wrote:
> > Read the beta pages: 3.7 has MP capability
>   3.7 has SMP capability, but it doesn't yet have clustering capabilities.
ooops, must have overread the cluster part.

Aydan

[Warp] Re: MPI with povray [6566 days 11 hours and 30 minutes ago]

Mon, 28 Apr 2008 15:06:54 GMT

Aydan <hes### [at] hendrik-sachsenet> wrote:
> Read the beta pages: 3.7 has MP capability

  3.7 has SMP capability, but it doesn't yet have clustering capabilities.

-- 
                                                          - Warp

[Aydan] Re: MPI with povray [6566 days 12 hours and 2 minutes ago]

Mon, 28 Apr 2008 14:35:02 GMT

"horry" <nomail@nomail> wrote:
> Hi all!
> I am looking for an implemetation of povray that could be used with mpi, in
> order to make parallel rendering in our cluster.
> I have found an implementation called mpi-povray, but only works with the
> version 3.1g of povray, and we need work with a newer version.
>
> Thank you
> Omar

Read the beta pages: 3.7 has MP capability

Aydan

[horry] MPI with povray [6566 days 14 hours and 2 minutes ago]

Mon, 28 Apr 2008 12:35:01 GMT

Hi all!
I am looking for an implemetation of povray that could be used with mpi, in
order to make parallel rendering in our cluster.
I have found an implementation called mpi-povray, but only works with the
version 3.1g of povray, and we need work with a newer version.

Thank you
Omar

[Lukas Winter] Sturmian root solver speed up patch [6598 days 5 hours and 52 minutes ago]

Thu, 27 Mar 2008 20:45:01 GMT

This is a very simple patch to the source code of beta 25b (see
povray.programming). The changes are minimal. You can check them with a tool
like unix diff. The two longer parts I added to polysolv.cpp (Descartes' rule
of signs in Solve_Polynomial() and upper bound on roots in polysolv() ) could
be dropped because the most common shapes that support sturm already have good
bounds on the wanted roots (blob, lathe, prism, sphere_sweep, torus, not: sor,
poly).
I have not checked validity on every shape. Floating point inaccuracies cause
very slightly different results but do not decrease image quality.

[Lukas Winter] isosurface patch [6613 days 10 hours and 2 minutes ago]

Wed, 12 Mar 2008 16:35:01 GMT

The zip-file contains all changes I made to the POV 3.7 beta 25b source.

[alphaQuad] 3.6 >> 3.6.1 [6678 days 1 hour and 7 minutes ago]

Tue, 8 Jan 2008 01:30:01 GMT

this is a winmerge patch file for unix source

unclipped gamma and some file bug

can be used to upgrade povwin_s.zip windows source

[Grassblade] Sarah Tariq and Lorenzo Ibarria's SSS [6736 days 9 hours and 2 minutes ago]

Sat, 10 Nov 2007 17:35:01 GMT

Not sure if this is the right place to post this. Apologies if it isn't.
I just got Sarah Tariq's and Lorenzo Ibarria's SSS patch.
In Sarah Tariq's own words: "I haven't looked at the files in a while but it
looks like the main entrance for the sub surface scattering is the
DiffuseScattering call, which replaces the normal call to Diffuse inside
compute_lighted_texture (lighting.cpp)"

[Le Forgeron] texture interpolation for polygon [6768 days 5 hours and 22 minutes ago]

Tue, 9 Oct 2007 21:15:25 GMT

Hello,

I was wondering about the texture interpolation for triangles (in
mesh), and if it would be possible to have the same kind of
interpolation on a polygon (let's assume a simple without hole
polygon for the time being, thanks).
At first, I blocked on the zero division when evaluating at a vertex
of the polygon, but then I found the following idea (see picture).
Let's a,b,c,... be the euclidean distance (or its square, after all,
do we really need a slow square root ?) from the evaluated point F
to each vertex.
It must be the euclidean distance (or based on it), because of the
needed isotropy for the interpolation.
(rotations of small angles should not change the result)

The absolute weight of the texture at point A would be the product
of all the distance but the distance from A.
The relative weight (used to weight the real texture list) is of
course divided by the sum of all absolute weights.

On Vertex A, all weights are null but for A, which give r(A)=1, just
fine.
W(x) is always positive or null.
T is always positive (assuming a polygon of more than 2 points,
without duplicated vertex).
So the division is fine.

The only sad point (but is it really sad ?) is that on the middle of
A-B, the influence of others points is not null (that's also why I
might prefer the square of the distance: less influence for more
distant points).

Does anybody sees a flaw in this idea ?

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

[Le Forgeron] Re: model of a scene [6773 days 5 hours and 31 minutes ago]

Thu, 4 Oct 2007 21:06:38 GMT

Thanks you for your interest, it's just a more than five years old
picture... and you're the first to answer.

Le 03.10.2007 23:55, honnza nous fit lire :

> If you cover some parts of a mirror with paint, you don't get the mirror
> finish on the paint. Rather you get one texture of pure reflection partly
> covered with little reflecting green surface. This is what you get with
> layered & patterned textures.

Wouldn't it be simpler to handle the finish and pigments separatly ?
Unless you have a subsurface-scatering model (and you'd better fake
it than tracing all these rays), I do not see the point of having
layered finish: only the topmost one is the finish you will ever see.

It's a bit like normal, what would be the sense of layered normal ?
(averaged or whatever patterned, I can understand, but layered
normal is such a strange idea...)

> If you want a common finish to multiple textures you should use a clear
> texture over multiple pigment only textures because it is rather how it
> works in reality :-) (a thin film on the surface is what usually does
> reflect)

Or you can duplicate the finish everywhere, but what is your point ?

> But I agree layered pigments might come in handy though layered textures do
> exactly the same (apart from metallic, I presume).

They do the same, but layered textures just seems so wrong in the
scope that textures have reached.

> One warning, though:
> multiple textures each containing a finish get their finishes evaluated
> separately, tracing one ray multiple times
> 
I do not understand that.

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

[honnza] Re: POV Memory [6774 days 3 hours and 37 minutes ago]

Wed, 3 Oct 2007 23:00:00 GMT

Christopher James Huff <cja### [at] earthlinknet> wrote:
> In article <3eaeff00$1@news.povray.org>,
>  "Early Ehlinger" <ear### [at] respowercom> wrote:
>
> > You could do a bounding-sphere at the beginning of each element.  The parser
> > could then scan past the element quickly by checking open and close braces.
> > It would store the center and radius of the element.  Determining if the
> > element needs to be checked for ray collision is then simply a matter of
> > comparing the distance from the center of the bounding-sphere to the ray
> > with the radius of the bounding-sphere.  If it needs to be checked, the
> > parser would go back and read the entire element.
>
> This would require a bounding object to be specified for every object,
> and for the parser to save the entire text of each object associated
> with each bounds until it parses it, which will likely take more memory
> than the parsed object. This would just slow things down, eat up memory,
> and make things difficult for the user, as well as making the source
> code much more complex. And it adds yet another way for people to make
> mistakes, the manually specified bounding. POV originally used manual
> bounding, there's a reason it was automated.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Plus any side-effects (assignmets to global variables) would have to be
moved outside of objects.

OTOH it might be able to create an infinite number of objects:

#macro sph
union{
  bounded_by{sphere{0,0.9}}
  sphere{0,1 material{hollow_glass}}
  sph
  scale 0.9
}
#end sph

would be parsed as:
macro, aha... blah,blah,blah... ends here.
oh, we call it: union, bounded by a 0,0.9 sphere. Nice.
....
Oh, there's something unknown in this sphere, it is:
an union, let's see it.
It contains a sphere, it's made of thin glass.
Oh, there's another union here. I't bouded by a 0,0.81 sphere. We don't need
it now.
....

That might come in handy :-)
Maybe this could be activated selectively, e.g. by a
hold{container,containment} object. Rendering hold{c_er,c_ent} would mean:
if the ray hits the c_er it parses the c_ent. It effectively suppresses an
infinite (transfinite?) recursion. Until being hit it looks just like an
object lucky enough not to be hit yet. Easy to learn, hard to master.

BTW, the reality behaves just like that: a particle doesn't know its
position until you ask it (uncertainty principle) and it behaves
differently depending on when do you observe it (quantum interference).
The hold doesn't know its contents until you ask it (uncertainty principle)
and the time for it to be parsed(observed) may affect the results greatly.
This way you can e.g. make a ray sensor that only contains itself AND counts
the photons, possibly triggering something. You can even create multiple
detectors to store the ray position, even to a file.

I can see great possibilities in conditional parsing, especially transfinite
number of objects (fractals, lattices), with no fear of losing speed if used
well. The worst you can do is to create an infinite loop, which is already
simple to do.

[honnza] Re: model of a scene [6774 days 4 hours and 37 minutes ago]

Wed, 3 Oct 2007 22:00:01 GMT

Le Forgeron <jgr### [at] freefr> wrote:
> Seems to be the right group, at least I hope so.
>
> I had too much time waiting for the 3.5, so I played with 3.1 ...
>
> I tried to represent a scene with some UML goodies (not strictly sticking to the
> standard), and I'm wondering if it wouldn't be better to replace the layered_texture
> (in Cyan in the picture) with a layered_pigment (in Green), because it is rather
> how it works in reality.

If you cover some parts of a mirror with paint, you don't get the mirror
finish on the paint. Rather you get one texture of pure reflection partly
covered with little reflecting green surface. This is what you get with
layered & patterned textures.
If you want a common finish to multiple textures you should use a clear
texture over multiple pigment only textures because it is rather how it
works in reality :-) (a thin film on the surface is what usually does
reflect)
But I agree layered pigments might come in handy though layered textures do
exactly the same (apart from metallic, I presume). One warning, though:
multiple textures each containing a finish get their finishes evaluated
separately, tracing one ray multiple times

[Jim Holsenback] Re: Matlab [6911 days 2 hours and 47 minutes ago]

Sat, 19 May 2007 23:50:24 GMT

"maesla" <nomail@nomail> wrote in message 
news:web.464c7ab2fe719493fbdb934e0@news.povray.org...
> I tried this:
> system('"C:Documents and
> SettingsadminDesktopmegapov-1.2.1-windowsbinmegapov.exe"   +HI"d:Documents
> and SettingsadminMy DocumentsproyectopovrayrobotSimulator" +L"c:Program
> FilesPOV-Ray for Windows v3.6renderer" +I"d:Documents and SettingsadminMy
> DocumentsproyectopovrayrobotSimulatormovimiento_robot.pov"')

could it be that you are missing the baclkslash character altogeather in 
MANY places?

try something like this:   system('"C:\Documents and 
Settings\admin\Desktop\megapov-1.2.1-windows\bin\megapov.exe" 
+HI"d:\Documents and Settings\admin\My 
Documents\proyectopovrayrobot\Simulator" +L"c:\Program Files\POV-Ray for 
Windows v3.6\renderer" +I"d:\Documents and Settings\admin\My 
Documents\proyectopovrayrobot\Simulatormovimiento_robot.pov"')

by the way some of those path names look a little fishy to me, but hope you 
see what I mean by the missing backslash character as you transition to a 
new directory.

Jim

[maesla] Re: Matlab [6913 days 10 hours and 42 minutes ago]

Thu, 17 May 2007 15:55:02 GMT

I found what I want.
It's the megapov. With this you can render povray file from the command
lines.
And I found that the fuction to run function from the matlab is
system('...')
But know i hace problems with the megapov. Maybe someone can help me.
Imagine:
The path of the megapov is:
C:Documents and SettingsadminDesktopmegapov-1.2.1-windowsbin
The path of the file I want to render is :
d:Documents and SettingsadminMy DocumentsproyectopovrayrobotSimulator
The name of the file I want to render is:
robot_movement_eyefish.ini
The files I have to include are in the path:
d:Documents and SettingsadminMy DocumentsproyectopovrayrobotSimulator
The files .inc that megapov needs like colors.inc are in
C:Program FilesPOV-Ray for Windows v3.6include
The picture of the video I need to make i need to save in
d:Documents and SettingsadminMy Documentsproyectointerface
And I need the pictures in bmp

I tried this:
system('"C:Documents and
SettingsadminDesktopmegapov-1.2.1-windowsbinmegapov.exe"   +HI"d:Documents
and SettingsadminMy DocumentsproyectopovrayrobotSimulator" +L"c:Program
FilesPOV-Ray for Windows v3.6renderer" +I"d:Documents and SettingsadminMy
DocumentsproyectopovrayrobotSimulatormovimiento_robot.pov"')

With this result:

Cannot open INI file 'FilesPOV-Ray'.
Cannot process command-line due to a parse error.
This is not a valid command-line. Check the command-line for syntax errors,
correct them, and try again!
Valid command-line switches are explained in detail in the reference part of
the documentation.
To get a short list of command-line switches, use either the '-h', '-?',
'-help' or '--help' switch.
Failed to render file due to error(s)!

ans =

    -8

Really I don´t know what I hace to write, and I don`t find good
documentation

Thank you

[Arno] Re: Matlab [6913 days 16 hours and 52 minutes ago]

Thu, 17 May 2007 09:45:01 GMT

Look here:

http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_env/f0-12994.html
&#f0-38522

[triple r] Re: Matlab [6916 days 10 hours and 7 minutes ago]

Mon, 14 May 2007 16:30:02 GMT

Perhaps a better group to ask this in?  Doesn't bother me though...

No direct link, but type 'system' into the search box and hit OK:

http://www.mathworks.com/access/helpdesk/help/techdoc/index.html

This is very similar to the c system() call, as far as I know.  I'm not a
windows user, but something like system('povray x.ini'); seems to be what
you are describing.  I don't know exactly how to invoke POV-Ray from the
console, but maybe you just need the path name, e.g.
system('C:folderpovray').  Not sure.  Of course, you could also run Matlab
in batch mode:

http://www.ciser.cornell.edu/CRADC/consulting/batchmatlab.shtml

Then you would write a script to run a matlab job in batch mode (no user
interface, just runs silently and quits) and then immediately starts up the
command-line version of POV-Ray.  Again, not sure exactly how to do this in
Windows, but the principle should be the same, just a matter of figuring
out how to run all the commands from a command line.

 - Ricky

[maesla] Matlab [6916 days 11 hours and 27 minutes ago]

Mon, 14 May 2007 15:10:02 GMT

Hi!
I'm doing my final project to ends the carrer and I use in it povray.
The program is done in matlab, but there is a part in that I say << Please
run povray and execute X.ini. When it finish, press Enter>>
My question is if is there some way to run povray without to have to open
povray, open the file, and press the button run of the interface of the
povray.
I would like to have in matlab code something like run('povray x.ini');
I don´t know if this is possible..
In working in windows by the way.
I trieded to write povray in ms-dos console of the windows, but nothing.
Maybe in c is possible??
Thank you very much.

P.D:this is not important, but maybe is useful, who knows:
In matlab I calculate the coordinates of a robot walking in a labyrinth.I
write the coordinates in a file. Then I read the file in povray and I draw
what the robot would see (Its like to take real snapshot).

[einarabelc5] Re: MPI patch for povray 3.5c [6927 days 11 hours and 57 minutes ago]

Thu, 3 May 2007 14:40:04 GMT

Christoph Hormann <chr### [at] gmxde> wrote:
> Vadim wrote:
> >
> > For those who are interested in parallel versions of Povray - I found an
> > easy way to do this with any version of Povray. :) Read this article:
> >
> > http://u.pereslavl.ru/~vadim/MCSharp/docs/povray/index.php
>
> Which is just yet another
> split-render-into-tiles-and-render-with-multiple-instances-of-POV-Ray
> tool in someone's favourite pet language.
>
> Various tools already exist for this:
>
> http://www.imp.org/impfarm/default.asp
> http://www.it-berater.org/smpov.htm
> http://www.imagico.de/povany/index.html
>
> which offer more functionality (esp. distributing a render across
> different computers).
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Landscape of the week:
> http://www.imagico.de/ (Last updated 31 Oct. 2005)
> MegaPOV with mechanics simulation: http://megapov.inetart.net/

Hello:
Cristoph, as you already know from my previous posts regarding Povray and
Parallelization I´ve looking for a way to do distributed rendering with.
Of all the links you list which one do you recommend the most?

I think povany would be a good one to try.

SMPov looks good to but do you know if it runs on Linux?

Thank You.

[Andycadd] Re: Parsing Feature Question "pack and GO" o... [6997 days 22 hours and 7 minutes ago]

Thu, 22 Feb 2007 04:30:01 GMT

so there is file output within the SDL I looked but could not find the names
of the keywords I thank you for the zip of your sample file I will look at
it this weekend

again thx very much
Andrew

[Charles C] Re: Parsing Feature Question "pack and GO" o... [7002 days 4 hours and 17 minutes ago]

Sat, 17 Feb 2007 22:20:01 GMT

I'm attaching a reduced and untested example of what I meant...  I put it in
a macro because I think I was wrong in something I said before.  The file is
re-read each time the macro is called from another file which is less than
efficient but makes me think it probably wouldn't take all that memory.  It
kindof sounds like you already have the ability to create custom
partial-library libraries save or dispose of at will, so I'm a little less
clear on what you're after.  Anyway there's a lot you can do and different
ways you can do it using the string functions and file i/o of POV-Ray.
Charles

"Andycadd" <And### [at] comcastnet> wrote:
> I am intrigued with this idea, you are saying that the entire file need not
> be loaded but somehow "preparsed" within a macro loop of some sort, please
> explain this to me.  SDL is not my forte.  Currently I use autocad to model
> and a custom Autolisp file to access the geometry and translate it into POV
> and INC files.  I am considering pulling the texture file together with a
> string match from a text file, hence writing a texture file definition
> library file each time I access the geometry of the model.  Your idea would
> mean the library file could remain complete, in fact I could load all the
> texture libraries I have and only keep the textures I need.  Please if you
> have any details of this lemme know.  I could very easily change my code to
> lsit the names of the materials I wish to load.
>
> Is there open-file and write-line keywords within the SDL I could just use
> them to write an abbreviated texture file of what I need.
>
> Right now I use the custom tool in Autocad to write a group of includes and
> a single pov file, then in povray I click render and that is it, no editing
> or changing of anything, all the standard settings are prewritten by the
> tool.
>
>
> "Charles C" <nomail@nomail> wrote:
> > A simple & compatible-for-all approach (because it's SDL), less the details:
> >
> > I bet you could re-do each library so that within each file, each "entry" is
> > a #case within a giant #switch.  Then if each entry contained strings of SDL
> > rather than straight SDL you could easily automate building up a smaller
> > file's worth of textures or what-have-you.  (Yes that's treating a file as
> > a macro rather than defining the switch in a macro since we wouldn't want
> > to keep most of it in memory, and then running through it N times to cover
> > however many items we're picking out.)
> >
> > Charles
> >
> > "Andycadd" <And### [at] comcastnet> wrote:
> > > Has anyone created a "pack and go" style tool for povray?

[Andycadd] Re: Parsing Feature Question "pack and GO" o... [7002 days 21 hours and 27 minutes ago]

Sat, 17 Feb 2007 05:10:00 GMT

I am intrigued with this idea, you are saying that the entire file need not
be loaded but somehow "preparsed" within a macro loop of some sort, please
explain this to me.  SDL is not my forte.  Currently I use autocad to model
and a custom Autolisp file to access the geometry and translate it into POV
and INC files.  I am considering pulling the texture file together with a
string match from a text file, hence writing a texture file definition
library file each time I access the geometry of the model.  Your idea would
mean the library file could remain complete, in fact I could load all the
texture libraries I have and only keep the textures I need.  Please if you
have any details of this lemme know.  I could very easily change my code to
lsit the names of the materials I wish to load.

Is there open-file and write-line keywords within the SDL I could just use
them to write an abbreviated texture file of what I need.

Right now I use the custom tool in Autocad to write a group of includes and
a single pov file, then in povray I click render and that is it, no editing
or changing of anything, all the standard settings are prewritten by the
tool.

"Charles C" <nomail@nomail> wrote:
> A simple & compatible-for-all approach (because it's SDL), less the details:
>
> I bet you could re-do each library so that within each file, each "entry" is
> a #case within a giant #switch.  Then if each entry contained strings of SDL
> rather than straight SDL you could easily automate building up a smaller
> file's worth of textures or what-have-you.  (Yes that's treating a file as
> a macro rather than defining the switch in a macro since we wouldn't want
> to keep most of it in memory, and then running through it N times to cover
> however many items we're picking out.)
>
> Charles
>
> "Andycadd" <And### [at] comcastnet> wrote:
> > Has anyone created a "pack and go" style tool for povray?

[Charles C] Re: Parsing Feature Question "pack and GO" o... [7012 days 19 hours and 42 minutes ago]

Wed, 7 Feb 2007 06:55:00 GMT

A simple & compatible-for-all approach (because it's SDL), less the details:

I bet you could re-do each library so that within each file, each "entry" is
a #case within a giant #switch.  Then if each entry contained strings of SDL
rather than straight SDL you could easily automate building up a smaller
file's worth of textures or what-have-you.  (Yes that's treating a file as
a macro rather than defining the switch in a macro since we wouldn't want
to keep most of it in memory, and then running through it N times to cover
however many items we're picking out.)

Charles

"Andycadd" <And### [at] comcastnet> wrote:
> Has anyone created a "pack and go" style tool for povray?

[Charles C] Re: Parsing Feature Question "pack and GO" o... [7012 days 20 hours and 22 minutes ago]

Wed, 7 Feb 2007 06:15:00 GMT

Technicality-humor.  "cut & ..." versus "copy & ..."




Warp <war### [at] tagpovrayorg> wrote:
> Andycadd <And### [at] comcastnet> wrote:
> > > > Currently I cut and paste the textures
> > >
> > >   Nitpicking, but I bet you don't.
>
> > I'll Bet I do
>
>   Why would you destroy the original texture declarations?
>
> --
>                                                           - Warp

[Warp] Re: Parsing Feature Question "pack and GO" o... [7013 days 3 hours and 46 minutes ago]

Tue, 6 Feb 2007 22:51:09 GMT

Andycadd <And### [at] comcastnet> wrote:
> > > Currently I cut and paste the textures
> >
> >   Nitpicking, but I bet you don't.

> I'll Bet I do

  Why would you destroy the original texture declarations?

-- 
                                                          - Warp

[Andycadd] Re: Parsing Feature Question "pack and GO" o... [7013 days 4 hours and 32 minutes ago]

Tue, 6 Feb 2007 22:05:00 GMT

Warp <war### [at] tagpovrayorg> wrote:
> Andycadd <And### [at] comcastnet> wrote:
> > Currently I cut and paste the textures
>
>   Nitpicking, but I bet you don't.
>
> --
>                                                           - Warp

I'll Bet I do
as I have over 5 thousand named colors each with a texture or 2
and over 3 thousand named texture tiles

I only have 2 gig of Ram  so the renderer crashes after parsing 4 thousand
materials, or much less if I use image tiles.

[Warp] Re: Parsing Feature Question "pack and GO" o... [7015 days 3 hours and 26 minutes ago]

Sun, 4 Feb 2007 23:10:52 GMT

Andycadd <And### [at] comcastnet> wrote:
> Currently I cut and paste the textures

  Nitpicking, but I bet you don't.

-- 
                                                          - Warp

[Andycadd] Parsing Feature Question "pack and GO" or "b... [7015 days 7 hours and 52 minutes ago]

Sun, 4 Feb 2007 18:45:00 GMT

Has anyone created a "pack and go" style tool for povray?

Basically a tool to take the multiple include files
and strip out all the unused items writing a single POV file sequenced
for rendering.

I ask because I tend to put all my new textures and shapes into a small
number of files and then call them all during the first parse.  I recently
generated a bunch of color files from most of the paint companies and even
larger image mapping files from the architectural finish companies
(wallpapers, siding, etc...).  Currently I cut and paste the textures I
want from the very large, many thousand of textures, texture/material
library files, this works but is not very convenient.

This feature would not render and would infact have to parse, basically in
reverse, finding all the objects and their textures and then finding all
their definition files and then finding all the constants and variables.

While I've never been a big fan of image_maps, the flooring, wallpaper and
siding companies have a large number of Named texture tiles available on
their sites and taking advantage of that resource only makes sense.

As for colors I have found 5 or 6 thousand  RGB listings of named colors and
used spreadsheets to defin/declare them all to their manufacturers names.

Attached are the color texture and normal files from all the silk thread
manufacturers I could find the "finnorm.inc" file is used as defaults for
all the different textures I have set up so far.

[Jack Keong] Re: MPI patch for povray 3.5c [7136 days 18 hours and 7 minutes ago]

Fri, 6 Oct 2006 08:30:00 GMT

Hi everyone,

I tried to setup mpi-povray based on Matthias patch, but i got this error
when i type make:

: undefined reference to `__ctype_b'
collect2: ld returned 1 exit status
make[1]: *** [povray] Error 1
make[1]: Leaving directory `/opt/povray3.5/povray-3.50c/src'
make: *** [all-recursive] Error 1

anyone have any idea bout this? thanx in advance!

Jack

"djzielin" <djz### [at] dukeedu> wrote:
> ah...I used wget to download the file, and I am able to unpack it.
>
> Best,
> -Dave
>
> "djzielin" <djz### [at] dukeedu> wrote:
> > Matthias <mat### [at] webde> wrote:
> > > Hi folks,
> > >
> > > based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> > > quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> > > Irix.
> > > It works with the new automake/autoconf system of povray 3.5, so just
> > > unpack the archive to your povray directory and run './configure',
> > > 'make' and 'make install', nothing new for you guys ;-)
> > > It has statistics, options and other stuff, so try it out!!
> > > Requirements are povray3.5c and LAM/MPI 6.5.x
> > > What do you think about it??
> > > If you like it, I hope it can be added to the tools section on the
> > > povray homepage...
> > >
> > > Matthias
> >
> > I think this file is corrupted. I have tried downloading it several times.
> > And made sure to clear the cache of the browser and delete the original
> > copy between tries. tar gives me errors when I try to unpack it. Is this
> > file hosted anywhere else?
> >
> > Thanks,
> > -Dave

[djzielin] Re: MPI patch for povray 3.5c [7361 days 10 hours and 52 minutes ago]

Thu, 23 Feb 2006 15:45:00 GMT

ah...I used wget to download the file, and I am able to unpack it.

Best,
-Dave

"djzielin" <djz### [at] dukeedu> wrote:
> Matthias <mat### [at] webde> wrote:
> > Hi folks,
> >
> > based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> > quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> > Irix.
> > It works with the new automake/autoconf system of povray 3.5, so just
> > unpack the archive to your povray directory and run './configure',
> > 'make' and 'make install', nothing new for you guys ;-)
> > It has statistics, options and other stuff, so try it out!!
> > Requirements are povray3.5c and LAM/MPI 6.5.x
> > What do you think about it??
> > If you like it, I hope it can be added to the tools section on the
> > povray homepage...
> >
> > Matthias
>
> I think this file is corrupted. I have tried downloading it several times.
> And made sure to clear the cache of the browser and delete the original
> copy between tries. tar gives me errors when I try to unpack it. Is this
> file hosted anywhere else?
>
> Thanks,
> -Dave

[djzielin] Re: MPI patch for povray 3.5c [7363 days 5 hours and 22 minutes ago]

Tue, 21 Feb 2006 21:15:00 GMT

Matthias <mat### [at] webde> wrote:
> Hi folks,
>
> based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> Irix.
> It works with the new automake/autoconf system of povray 3.5, so just
> unpack the archive to your povray directory and run './configure',
> 'make' and 'make install', nothing new for you guys ;-)
> It has statistics, options and other stuff, so try it out!!
> Requirements are povray3.5c and LAM/MPI 6.5.x
> What do you think about it??
> If you like it, I hope it can be added to the tools section on the
> povray homepage...
>
> Matthias

I think this file is corrupted. I have tried downloading it several times.
And made sure to clear the cache of the browser and delete the original
copy between tries. tar gives me errors when I try to unpack it. Is this
file hosted anywhere else?

Thanks,
-Dave

[NEWS] Re: Difference [7384 days 7 hours and 21 minutes ago]

Tue, 31 Jan 2006 19:16:24 GMT

you got
union {

    box texture {red}
    box texture {blue}
}
and you want to subtract
box texture {black}
without black coor

then do this

intersection {
            union {
                    box red
                    box blue
                }

            box {<...>,<...> texture {black} inverse}
}


insteed of getting the difference ,   une the intersection of your object
with all_the_outside of you second object by using the inverse keyword into
your black box





"Alvaro Blanco" <abl### [at] icmmcsices> a écrit dans le message de
news:43971e49$1@news.povray.org...
> Hello Roman, Thanks for your quick response.
> Maybe I was also too quick when I wrote the question.
> The problem is the folowing:
>
> Imagine that I have 2 boxes: 1 is red and the other is blue and they are
> one ontop of the other. If I cut this with a Black box I obtain a black
> edge. But i want the edge red and blue. It is not a problem of total
> pigments or final pigments (or textures), the problem is that i want to
> see the "real" cut of the first object. Maybe this is just fundamental
> problem in Pov-ray because all objects are empty and you only see
> surfaces. I was just wondering if anybody have had this problem and have
>   solved it. Imagine that you have a Ham and Cheese Sandwich and u cut
> it with a red knife. I don't want to see a red cut but the edge of the
> bread, the ham and the cheese.
>
> Alvaro
>
> Roman Reiner wrote:
>
> > First of all this is the wrong newsgroup. such questions should be
posted in
> > newusers http://news.povray.org/povray.newusers/
> >
> > To answer your question. When i understand you right you want the
resulting
> > object to have one overall texture. in this case it is the easiest way
not
> > to use pigments (or textures) in the single object declarations but
apply
> > it once to the resulting cutobject. for example
> >
> > difference {
> >   object { this }
> >   difference {
> >     object { that }
> >     merge {
> >       object { whatever }
> >       ...
> >     }
> >   }
> >   ...
> >   texture { myTexture }
> > }
> >
> > Hope that helped
> > Regards Roman
> >
> > Alvaro Blanco <abl### [at] icmmcsices> wrote:
> >
> >>Hello all,
> >>This is my first post and maybe I ask a silly (beginner) question: When
> >>you use difference you get the color of the object you substract. When
> >>you substract something easy, let's say, a box A minus a box B, then it
> >>is easy to get the right color in your cut surface. You just use the
> >>same color for B. But, when A is something composed of many different
> >>objects with many different colors... Is there any way or "trick" to get
> >>this colors in the cut edge instead of the same color of B?
> >>Thanks
> >
> >
> >
> >

[Alvaro Blanco] Re: Difference [7437 days 15 hours and 41 minutes ago]

Fri, 9 Dec 2005 10:56:21 GMT

Thanks!! I will eat it today!

3.5.10 hidden in the middle of the tutorial. It should be placed in 
difference section or, at least, there should be a hyperlink to 3.5.10 
from there.

:-) Alvaro

JYR wrote:
> 3.5.10
> cutaway_textures
> 
> Your sandwich should now be properly cut :)
> 
> JYR
>

[Roman Reiner] Re: Difference [7439 days 1 hour and 47 minutes ago]

Thu, 8 Dec 2005 00:50:00 GMT

"JYR" <jyr### [at] hotmailcom> wrote:
> 3.5.10
> cutaway_textures
>
> Your sandwich should now be properly cut :)
>
> JYR

hehe. didn't know that. still learning ;-)

[JYR] Re: Difference [7439 days 8 hours and 17 minutes ago]

Wed, 7 Dec 2005 18:20:00 GMT

3.5.10
cutaway_textures

Your sandwich should now be properly cut :)

JYR

[Roman Reiner] Re: Difference [7439 days 8 hours and 27 minutes ago]

Wed, 7 Dec 2005 18:10:01 GMT

This is much more complicated and i do not have a quick solution for that
and consulting my conception of how csg is being calculated i doubt there
is one. when you (for example) intersect to objects povray traces both
objects and when both are hit it uses the intersection point that is farer
away.
the ray just intersects with surfaces. there's no the interior (except you
use media but i doubt this would be a good solution it that case ;-)).
therefore the ray gets the color of the object whose surface has been hit.
in your example the red knife.
surely one can can trick around that when the object isn't too complicated.
maybe an other user already had experiences with that. i hadn't

Regards Roman

Alvaro Blanco <abl### [at] icmmcsices> wrote:
> Hello Roman, Thanks for your quick response.
> Maybe I was also too quick when I wrote the question.
> The problem is the folowing:
>
> Imagine that I have 2 boxes: 1 is red and the other is blue and they are
> one ontop of the other. If I cut this with a Black box I obtain a black
> edge. But i want the edge red and blue. It is not a problem of total
> pigments or final pigments (or textures), the problem is that i want to
> see the "real" cut of the first object. Maybe this is just fundamental
> problem in Pov-ray because all objects are empty and you only see
> surfaces. I was just wondering if anybody have had this problem and have
>   solved it. Imagine that you have a Ham and Cheese Sandwich and u cut
> it with a red knife. I don't want to see a red cut but the edge of the
> bread, the ham and the cheese.
>
> Alvaro
>
> Roman Reiner wrote:
>
> > First of all this is the wrong newsgroup. such questions should be posted in
> > newusers http://news.povray.org/povray.newusers/
> >
> > To answer your question. When i understand you right you want the resulting
> > object to have one overall texture. in this case it is the easiest way not
> > to use pigments (or textures) in the single object declarations but apply
> > it once to the resulting cutobject. for example
> >
> > difference {
> >   object { this }
> >   difference {
> >     object { that }
> >     merge {
> >       object { whatever }
> >       ...
> >     }
> >   }
> >   ...
> >   texture { myTexture }
> > }
> >
> > Hope that helped
> > Regards Roman
> >
> > Alvaro Blanco <abl### [at] icmmcsices> wrote:
> >
> >>Hello all,
> >>This is my first post and maybe I ask a silly (beginner) question: When
> >>you use difference you get the color of the object you substract. When
> >>you substract something easy, let's say, a box A minus a box B, then it
> >>is easy to get the right color in your cut surface. You just use the
> >>same color for B. But, when A is something composed of many different
> >>objects with many different colors... Is there any way or "trick" to get
> >>this colors in the cut edge instead of the same color of B?
> >>Thanks
> >
> >
> >
> >

[Alvaro Blanco] Re: Difference [7439 days 8 hours and 58 minutes ago]

Wed, 7 Dec 2005 17:39:21 GMT

Hello Roman, Thanks for your quick response.
Maybe I was also too quick when I wrote the question.
The problem is the folowing:

Imagine that I have 2 boxes: 1 is red and the other is blue and they are 
one ontop of the other. If I cut this with a Black box I obtain a black 
edge. But i want the edge red and blue. It is not a problem of total 
pigments or final pigments (or textures), the problem is that i want to 
see the "real" cut of the first object. Maybe this is just fundamental 
problem in Pov-ray because all objects are empty and you only see 
surfaces. I was just wondering if anybody have had this problem and have 
  solved it. Imagine that you have a Ham and Cheese Sandwich and u cut 
it with a red knife. I don't want to see a red cut but the edge of the 
bread, the ham and the cheese.

Alvaro

Roman Reiner wrote:

> First of all this is the wrong newsgroup. such questions should be posted in
> newusers http://news.povray.org/povray.newusers/
> 
> To answer your question. When i understand you right you want the resulting
> object to have one overall texture. in this case it is the easiest way not
> to use pigments (or textures) in the single object declarations but apply
> it once to the resulting cutobject. for example
> 
> difference {
>   object { this }
>   difference {
>     object { that }
>     merge {
>       object { whatever }
>       ...
>     }
>   }
>   ...
>   texture { myTexture }
> }
> 
> Hope that helped
> Regards Roman
> 
> Alvaro Blanco <abl### [at] icmmcsices> wrote:
> 
>>Hello all,
>>This is my first post and maybe I ask a silly (beginner) question: When
>>you use difference you get the color of the object you substract. When
>>you substract something easy, let's say, a box A minus a box B, then it
>>is easy to get the right color in your cut surface. You just use the
>>same color for B. But, when A is something composed of many different
>>objects with many different colors... Is there any way or "trick" to get
>>this colors in the cut edge instead of the same color of B?
>>Thanks
> 
> 
> 
>

[Roman Reiner] Re: Difference [7439 days 9 hours and 17 minutes ago]

Wed, 7 Dec 2005 17:20:00 GMT

First of all this is the wrong newsgroup. such questions should be posted in
newusers http://news.povray.org/povray.newusers/

To answer your question. When i understand you right you want the resulting
object to have one overall texture. in this case it is the easiest way not
to use pigments (or textures) in the single object declarations but apply
it once to the resulting cutobject. for example

difference {
  object { this }
  difference {
    object { that }
    merge {
      object { whatever }
      ...
    }
  }
  ...
  texture { myTexture }
}

Hope that helped
Regards Roman

Alvaro Blanco <abl### [at] icmmcsices> wrote:
> Hello all,
> This is my first post and maybe I ask a silly (beginner) question: When
> you use difference you get the color of the object you substract. When
> you substract something easy, let's say, a box A minus a box B, then it
> is easy to get the right color in your cut surface. You just use the
> same color for B. But, when A is something composed of many different
> objects with many different colors... Is there any way or "trick" to get
> this colors in the cut edge instead of the same color of B?
> Thanks

[Alvaro Blanco] Difference [7439 days 9 hours and 34 minutes ago]

Wed, 7 Dec 2005 17:03:19 GMT

Hello all,
This is my first post and maybe I ask a silly (beginner) question: When 
you use difference you get the color of the object you substract. When 
you substract something easy, let's say, a box A minus a box B, then it 
is easy to get the right color in your cut surface. You just use the 
same color for B. But, when A is something composed of many different 
objects with many different colors... Is there any way or "trick" to get 
this colors in the cut edge instead of the same color of B?
Thanks

[Christoph Hormann] Re: MPI patch for povray 3.5c [7447 days 11 hours and 59 minutes ago]

Tue, 29 Nov 2005 14:38:45 GMT

Vadim wrote:
> 
> For those who are interested in parallel versions of Povray - I found an
> easy way to do this with any version of Povray. :) Read this article:
> 
> http://u.pereslavl.ru/~vadim/MCSharp/docs/povray/index.php

Which is just yet another 
split-render-into-tiles-and-render-with-multiple-instances-of-POV-Ray 
tool in someone's favourite pet language.

Various tools already exist for this:

http://www.imp.org/impfarm/default.asp
http://www.it-berater.org/smpov.htm
http://www.imagico.de/povany/index.html

which offer more functionality (esp. distributing a render across 
different computers).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

[Thorsten Froehlich] Re: MPI patch for povray 3.5c [7447 days 12 hours and 27 minutes ago]

Tue, 29 Nov 2005 14:10:42 GMT

Vadim wrote:
> For those who are interested in parallel versions of Povray - I found an
> easy way to do this with any version of Povray. :) Read this article:
> 
> http://u.pereslavl.ru/~vadim/MCSharp/docs/povray/index.php

... which happens to contain various incorrect statements about the 
development of POV-Ray.  In particular the lengthy paragraph about the 
"owner" and "developer" of POV-Ray is all wrong.  Persistence of Vision 
Raytracer Pty. Ltd. only holds the copyright in order to protect individual 
developers (against patent lawsuits, illegal use of POV-Ray, etc), it does 
not develop POV-Ray.  This is a same setup similar to what most open source 
projects are forced to use these days.  The paragraph also claims the 
official version is not developed by volunteers, which is plain wrong, too.

	Thorsten

[Vadim] Re: MPI patch for povray 3.5c [7447 days 15 hours and 2 minutes ago]

Tue, 29 Nov 2005 11:35:01 GMT

Matthias <mat### [at] webde> wrote:
> Hi folks,
>
> based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> Irix.
> It works with the new automake/autoconf system of povray 3.5, so just
> unpack the archive to your povray directory and run './configure',
> 'make' and 'make install', nothing new for you guys ;-)
> It has statistics, options and other stuff, so try it out!!
> Requirements are povray3.5c and LAM/MPI 6.5.x
> What do you think about it??
> If you like it, I hope it can be added to the tools section on the
> povray homepage...
>
> Matthias

For those who are interested in parallel versions of Povray - I found an
easy way to do this with any version of Povray. :) Read this article:

http://u.pereslavl.ru/~vadim/MCSharp/docs/povray/index.php


Best regards,
Vadim B. Guzev
http://u.pereslavl.ru/~vadim/MCSharp/

[Mike Williams] Re: Blueprint output [7677 days 21 hours and 50 minutes ago]

Wed, 13 Apr 2005 04:46:55 GMT

Wasn't it Steely who wrote:
>Mike Williams <nos### [at] econymdemoncouk> wrote:
>
>> For a real blueprint, you probably don't want a wireframe of the whole
>> house, what you want is a slice through the house, like this:
>
>Don´t know if this would match in all and any cases, but more important: any
>workaround to overcome the object pattern limitation of "no texture, no
>patches" ?

It would certainly be easier to change the POV program to remove those
limitations than it would be to get it to produce wireframe renderings
of things like isosurfaces and blobs.

>If I have to construct two buildings, one with, one without textures and
>patches, I´ll better go on with my (ugly hand-drawn) sketches ;-)

Instead of the object pattern, you could difference the building with a
thin box. The textures from the original building would only appear on
the faces that are perpendicular to the camera, and therefore invisible.

difference {
  box {<-100,0.1,-100><100,0.1001,100>}
  object {House}
  pigment {rgb <0,0,1>}
  finish {ambient 1}
}

// white bits seen through the hole
plane {y,0 pigment {rgb 1} finish {ambient 1}}

-- 
Mike Williams
Gentleman of Leisure

[Steely] Re: Blueprint output [7678 days 7 hours and 32 minutes ago]

Tue, 12 Apr 2005 19:05:01 GMT

Mike Williams <nos### [at] econymdemoncouk> wrote:

> For a real blueprint, you probably don't want a wireframe of the whole
> house, what you want is a slice through the house, like this:

Don´t know if this would match in all and any cases, but more important: any
workaround to overcome the object pattern limitation of "no texture, no
patches" ?

If I have to construct two buildings, one with, one without textures and
patches, I´ll better go on with my (ugly hand-drawn) sketches ;-)

S.

[Mike Williams] Re: Blueprint output [7678 days 12 hours and 10 minutes ago]

Tue, 12 Apr 2005 14:26:59 GMT

Wasn't it Steely who wrote:
>Hi, folks!
>
>I am not a programmer, so I don´t have a clue if this is an easy task or if
>you will hang me for the question. The idea is, to have a render output
>option for making blueprints of the scene, like the wireframe- or edge-view
>option in other programs. Something like the +UD option, but for the shapes
>insted of the bounding boxes.
>
>I suppose, it will not be easy, as POVRay doesn´t have polygons, but it
>would be a great help when making real huge buildings and such things, to
>have a bluprint where you can write down measures and distances and such.
>
>Just thinking .... ;-)
>

For a real blueprint, you probably don't want a wireframe of the whole
house, what you want is a slice through the house, like this:

plane {y,0.1
  pigment {
  object
    { House
      rgb <0,0,1>
      rgb 1
    }
  }
}



-- 
Mike Williams
Gentleman of Leisure

[Mike Raiford] Re: hemispherical projection camera [7678 days 14 hours and 19 minutes ago]

Tue, 12 Apr 2005 12:18:37 GMT

pacoit wrote:
> I would like to develop a camera type that projects an image at the inside
> of a hemispherical surface (as opposed to a flat surface as with
> perspective camera). The purpose is to generate wide-angle views (up to
> 180deg, theoretically). Yes, the widest views would be curvilinear; but up
> to ~120deg views should look pretty good. I would like to know: (1) if
> someone has already developed such a camera; and (2) if someone can offer a
> pointer to a description of the math to do this?
> 
> Thank you.
> 

It's in the docs and this is not the appropriate forum for this type of 
question. This is designed for people who work on the source code of povray.

-- 
~Mike

Things! Billions of them!

[Steely] Blueprint output [7678 days 14 hours and 42 minutes ago]

Tue, 12 Apr 2005 11:55:00 GMT

Hi, folks!

I am not a programmer, so I don´t have a clue if this is an easy task or if
you will hang me for the question. The idea is, to have a render output
option for making blueprints of the scene, like the wireframe- or edge-view
option in other programs. Something like the +UD option, but for the shapes
insted of the bounding boxes.

I suppose, it will not be easy, as POVRay doesn´t have polygons, but it
would be a great help when making real huge buildings and such things, to
have a bluprint where you can write down measures and distances and such.

Just thinking .... ;-)

Steely

[Le Forgeron] Re: hemispherical projection camera [7678 days 19 hours and 12 minutes ago]

Tue, 12 Apr 2005 07:25:46 GMT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wrong forum so far, no binary attachment detected.

pacoit wrote:
> I would like to develop a camera type that projects an image at the inside
> of a hemispherical surface (as opposed to a flat surface as with
> perspective camera). The purpose is to generate wide-angle views (up to
> 180deg, theoretically). Yes, the widest views would be curvilinear; but up
> to ~120deg views should look pretty good. I would like to know: (1) if
> someone has already developed such a camera; and (2) if someone can offer a
> pointer to a description of the math to do this?
> 

What about reading the documentation ?
Especially the sub-...-chapter about spherical projection in Pov-ray
Reference/Scene Settings/Camera/Types of projection.
(That should be 3.3.1.2.8 of the windows documentation, just launch
povray, hit F1 and there you are!)

So, I believe:
(1) Yes
(2) At worst, you could look at the code of the relevant camera.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCW3f5s/YJ43cSjHIRAjypAJ9o4E9eVULpYdtljnDusMpGYg/fmACcCYa6
2t0KVXH/FABy10Hbyz74zJY=
=D1AR
-----END PGP SIGNATURE-----

[pacoit] hemispherical projection camera [7679 days 5 hours and 42 minutes ago]

Mon, 11 Apr 2005 20:55:00 GMT

I would like to develop a camera type that projects an image at the inside
of a hemispherical surface (as opposed to a flat surface as with
perspective camera). The purpose is to generate wide-angle views (up to
180deg, theoretically). Yes, the widest views would be curvilinear; but up
to ~120deg views should look pretty good. I would like to know: (1) if
someone has already developed such a camera; and (2) if someone can offer a
pointer to a description of the math to do this?

Thank you.

[Robert] Re: variable debugging [7774 days 8 hours and 37 minutes ago]

Thu, 6 Jan 2005 18:00:04 GMT

Sorry for posting in the wrong group, and thank's for redirecting and 
answering.

Robert

> Not the correct group. This is for people who muck with the source code. 
> I've copied this to povray.general .. which is the proper group.
>
> To answer your question:
>
> #debug "\n"
>
> will give you a line break.
>
>
> -- 
> ~Mike

[Mike Raiford] Re: variable debugging [7774 days 9 hours and 4 minutes ago]

Thu, 6 Jan 2005 17:33:46 GMT

Robert wrote:
> Hi there,
> 
> i`m trying to programm a little bit in povray and would see the values of 
> variables I programmed. This works fine so far with the #debug argument, but 
> when I want to output more than one variable via #debug, all is written in a 
> row. How can I perform a line brake?
> 
> Many thanks for help,
> 
> Robert
> 
> example:
> 
> #debug concat("  h1=",vstr(3, h1, ",", 0,1))
> #debug concat("  k1=",vstr(3, k1, ",", 0,1))
> #debug concat("  l1=",vstr(3, l1, ",", 0,1))
> #debug concat("  a=",vstr(3, h, ",", 0,1))
> #debug concat("  b=",vstr(3, k, ",", 0,1))
> #debug concat("  c=",vstr(3, l, ",", 0,1))
> #debug concat("  P=",vstr(3, P, ",", 0,1))
> #debug concat("  M1=",vstr(3, M1, ",", 0,1))
> #debug concat("  M2=",vstr(3, M2, ",", 0,1)) 

Not the correct group. This is for people who muck with the source code. 
I've copied this to povray.general .. which is the proper group.

To answer your question:

#debug "\n"

will give you a line break.


-- 
~Mike

[Robert] variable debugging [7774 days 10 hours and 20 minutes ago]

Thu, 6 Jan 2005 16:16:59 GMT

Hi there,

i`m trying to programm a little bit in povray and would see the values of 
variables I programmed. This works fine so far with the #debug argument, but 
when I want to output more than one variable via #debug, all is written in a 
row. How can I perform a line brake?

Many thanks for help,

Robert

example:

#debug concat("  h1=",vstr(3, h1, ",", 0,1))
#debug concat("  k1=",vstr(3, k1, ",", 0,1))
#debug concat("  l1=",vstr(3, l1, ",", 0,1))
#debug concat("  a=",vstr(3, h, ",", 0,1))
#debug concat("  b=",vstr(3, k, ",", 0,1))
#debug concat("  c=",vstr(3, l, ",", 0,1))
#debug concat("  P=",vstr(3, P, ",", 0,1))
#debug concat("  M1=",vstr(3, M1, ",", 0,1))
#debug concat("  M2=",vstr(3, M2, ",", 0,1))

[Shawn Somers] Looking for a scene/model [7790 days 15 hours and 42 minutes ago]

Tue, 21 Dec 2004 10:55:03 GMT

I'm looking for a moray/pov compatible model of a turbocharger. Anyone 
have one??


Shawn Somers

[zmemw16] Re: how does spatch work technically? [7811 days 4 hours and 32 minutes ago]

Tue, 30 Nov 2004 22:05:00 GMT

"DocJunioR" <doc### [at] webde> wrote:
> Hello,
>
> I want to create an animation tool for POV including a simple scene
> modeller.
> So I am interested in other modellers. Most simple program I know is sPatch.
>
> Does anyone know how it works ?
> It has splines, where the points are used as waypoints.
> What I'm interestet in is the decision whether a polygon is visible or not.
> Has anyone ever seen a source code ?
> If so, please post it.. :)
>
> greetz from Germany

you might want to take a look at jpatch
source is available

search on freshmeat.net/sourceforge.org

might just save re-inventing the wheel :-)

stephen

[DocJunioR] how does spatch work technically? [7811 days 19 hours and 2 minutes ago]

Tue, 30 Nov 2004 07:35:00 GMT

Hello,

I want to create an animation tool for POV including a simple scene
modeller.
So I am interested in other modellers. Most simple program I know is sPatch.

Does anyone know how it works ?
It has splines, where the points are used as waypoints.
What I'm interestet in is the decision whether a polygon is visible or not.
Has anyone ever seen a source code ?
If so, please post it.. :)

greetz from Germany

[Rick Gutleber] Re: POV-Ray without CodeMax editor [7838 days and 16 minutes ago]

Thu, 4 Nov 2004 02:21:44 GMT

òÏÍÁÎ
÷ÌÁÄÉÍÉÒÏ×ÉÞ
÷ÑÔËÉÎ wrote:
> Hi there.
> It's possible make POV-Ray without GUI, simple console version?
> 
> 

I think you can build the Linux version under Windows.  The Linux 
version doesn't have the GUI as I understand it.  Of course, this may 
have changed in the last couple years.

[] POV-Ray without CodeMax editor [7839 days 15 hours and 58 minutes ago]

Tue, 2 Nov 2004 10:39:41 GMT

Hi there.
It's possible make POV-Ray without GUI, simple console version?

[Thorsten Froehlich] Re: MPI patch for povray 3.5c [7917 days 20 hours and 3 minutes ago]

Mon, 16 Aug 2004 06:34:35 GMT

In article <web.412000b94419f93c4661956a0@news.povray.org> , "" 
<nomail@nomail> wrote:

> great stuff. is there are place were i can download this file. it
> keep on getting corrupted when i try to tar xvzf the file.
>
> if not you can email it to me and i can post it somewhere.

The file on the server is OK.  You just got a corrupted download and your
repeated downloads are most likely from your browser cache rather than the
site.  Clear your browser cache and the restart your browser to be certain
it loads the file again.  If this does not help, use a more reliable
browser.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[nomail] Re: MPI patch for povray 3.5c [7918 days 2 hours and 2 minutes ago]

Mon, 16 Aug 2004 00:35:01 GMT

Matthias <mat### [at] webde> wrote:
> Hi folks,
>
> based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> Irix.
> It works with the new automake/autoconf system of povray 3.5, so just
> unpack the archive to your povray directory and run './configure',
> 'make' and 'make install', nothing new for you guys ;-)
> It has statistics, options and other stuff, so try it out!!
> Requirements are povray3.5c and LAM/MPI 6.5.x
> What do you think about it??
> If you like it, I hope it can be added to the tools section on the
> povray homepage...
>
great stuff. is there are place were i can download this file. it
keep on getting corrupted when i try to tar xvzf the file.

if not you can email it to me and i can post it somewhere.

thanks.

[A Brinkmann] Patch for media_attenuation bug [7936 days 8 hours and 52 minutes ago]

Wed, 28 Jul 2004 17:45:45 GMT

Hi,

I attached a patch for the media_attenuation bug discussed in the
general newsgroup last week, the thread is called "Fog and media
(once again...)". You will only encounter this bug if you use fog
and media in your scene, with media_attenuation for your light
source turned off (which is the default).

I also attached a picture showing the before/after difference, and
the scene used to produce that picture.

I'm not an experienced POV hacker, so my solution might not be the
best... feedback is welcome, of course. Anyway, I hope somebody
will have a use for it.

[haugboel] Re: MPI patch for povray 3.5c [7939 days 14 hours and 52 minutes ago]

Sun, 25 Jul 2004 11:45:00 GMT

Matthias <mat### [at] webde> wrote:
> Hi folks,
>
> based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> Irix.

> Requirements are povray3.5c and LAM/MPI 6.5.x
> What do you think about it??
I like it very much!
We use POVRay for rendering images to scientific publications, and need
sometimes to do very large images (think 600dpi). We have access to several
large (512 cpu size) installations. Both SMP machines and clusters. To get
the job done unfortunately we need povray 3.6.
Is there any chance you will port your patch to POVRay 3.6 ? I tried naively
to just dump parapov in the 3.6 source, and it didn't work. I would be
happy to help test - also large scale (up to 128 CPU) - runs if
needed/wanted.

Regards,

Troels

[RTRT buff] Re: Virtual Realiy [7979 days 22 hours and 57 minutes ago]

Tue, 15 Jun 2004 03:40:01 GMT

> Real time ray tracing is impossible at this time with the Personnal Computers we
> got...  You would probably need a super computer for this to be acheived...

RealTimeRrayTracing IS POSSIBLE


some RTRT demo @
http://www1.acm.org/pubs/tog/resources/RTNews/demos/overview.htm
the website includes some demos

"
Try, for example, running Gamma2 from Mfx in high resolution mode and
discover the real computational power of your processor. Sometimes people
don't even believe raytracing can be done at the speed of 10 or more frames
per second
"

just look on the net for "real time ray tracing"

[Nicolas Alvarez] Re: Diamond Rendering, PLz Evaluate !! [7992 days 3 hours and 55 minutes ago]

Wed, 2 Jun 2004 22:42:47 GMT

The message was in multipart: HTML for people that can see it and readable text
for people that can't.


"Rafal 'Raf256' Maj" <spa### [at] raf256com> escribió en el mensaje
news:Xns94B58CD6DC1C5raf256com@203.29.75.35...
> aze### [at] qwertygov news:405f91ae@news.povray.org
>
> > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>
> Please do not send posts in HTML.
>
> As for image - very nice, add some ground there to nicely show the
> photons refraction :)
>
>
> --
> http://www.raf256.com/3d/
> Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
> Computer Graphics

[Daniel Jungmann] MegaPov collision detection patch 2 [8055 days 6 hours and 9 minutes ago]

Wed, 31 Mar 2004 20:28:26 GMT

Hi!

This is the new collision detection patch for Megapov. For more information
visit povray.unofficial.patches "MegaPov collision detection".

[Alain] Re: Diamond Rendering, PLz Evaluate !! [8063 days 1 hour and 30 minutes ago]

Wed, 24 Mar 2004 01:07:05 GMT

Rafal 'Raf256' Maj nous apporta ses lumieres ainsi en ce 2004/03/23 
07:51... :

>aze### [at] qwertygov news:405f91ae@news.povray.org
>
>  
>
>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>>    
>>
>
>Please do not send posts in HTML.
>
>As for image - very nice, add some ground there to nicely show the 
>photons refraction :)
>
>
>  
>
Well, the original post WAS in HTML...

Alain

[Rafal 'Raf256' Maj] Re: Diamond Rendering, PLz Evaluate !! [8063 days 13 hours and 46 minutes ago]

Tue, 23 Mar 2004 12:51:01 GMT

aze### [at] qwertygov news:405f91ae@news.povray.org

> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Please do not send posts in HTML.

As for image - very nice, add some ground there to nicely show the 
photons refraction :)


-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

[Alain] Re: Diamond Rendering, PLz Evaluate !! [8064 days 1 hour and 13 minutes ago]

Tue, 23 Mar 2004 01:23:58 GMT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body>
I prefer the first. In the second, you lose the details in all those
reflections and refractions.<br>
<br>
Alain<br>
<br>
AsheZ nous apporta ses lumieres ainsi en ce 2003/12/21 14:43... : <br>
<blockquote cite="mid3fe5f7f7@news.povray.org" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2600.0" name="GENERATOR">
  <style></style>
  <div><font face="Arial" size="2"><img alt="" hspace="0"
 src="cid:par### [at] qwertygov" align="bottom" border="0"></font></div>
  <div> </div>
  <div><font face="Arial" size="2">2lac photons --></font> <br>
  </div>
</blockquote>
<br>
</body>
</html>

[Daniel Jungmann] MegaPov collision detection [8067 days 17 hours and 22 minutes ago]

Fri, 19 Mar 2004 09:15:38 GMT

Hi,

I have now written a patch for faster collision detection. I just made some
quick checks and it seems working but there might be still a lot of bugs.
Fee free to report them all.

The zipfile contains the changed source files (mechsim.cpp and mechsim.h)
and a diff file. You don't need both of them.

Daniel

[Andreas Kaiser] Re: Fix for improved intersection routine for C... [8102 days 6 hours and 17 minutes ago]

Fri, 13 Feb 2004 20:19:54 GMT

On Tue, 13 Jan 2004 09:59:00 GMT, kai### [at] siemenscom (Andreas
Kaiser) wrote:

>Attached you'll find csg.cpp with an improved intersection routine for
>CSG-Intersection objects (together with two small but necessary
>changes in Union- and Merge-intersection).

(I'm replying to myself here)

If you use this patch you should not place the subtracted objects into
a union/merge object.

Instead of 

intersection // or difference
  {
  object1
  union
    {
    object2
    object3
    ...
    }
  ...
  }

you should use

intersection // or difference
  {
  object1
  object2
  object3
  ...
  ...
  }


-- 
Andreas

[Andreas Kaiser] Fix for improved intersection routine for CSG-I... [8133 days 16 hours and 38 minutes ago]

Tue, 13 Jan 2004 09:59:00 GMT

Attached you'll find csg.cpp with an improved intersection routine for
CSG-Intersection objects (together with two small but necessary
changes in Union- and Merge-intersection).
To use this version of csg.cpp you must add a new define

#define CSG_SIBLING_IGNORE_FLAG 0x2000000L /*AKA: csg internal flag*/

to objects.h.
I've checked it with each scene file in the distribution that contains
intersection and/or difference objects and it should be ok now.

Bad News: Almost no difference for benchmark.pov (but see my reply to
a post of Christoph Horman in povray.programming).

Below you'll find some timings for my two private builds

- POV-L1R:	almost original (just changes to compile)
- POV-L2R:	improved CSG-Intersection (1st fixed version)

The files below were traced with [640x480, AA0.3] (AA being switched
off due to focal blur for chess2.pov).
Values are PPS / totaltime in sec.

				POV-L1R			POV-L2R
=====================================================================
advanced/chess2.pov:		1616 / 186		 2287 / 134
advanced/grenadine.pov:		2145 / 143		 2877 / 107
advanced/whiltile.pov:		7333 / 42		 8474 / 36
incdemo/shapes.pov:		8533 / 36		10108 / 30

Andreas

[Peter Popov] Re: #system patch [8178 days 15 hours and 57 minutes ago]

Sat, 29 Nov 2003 10:40:40 GMT

On Thu, 27 Nov 2003 15:44:04 +0100, ABX <abx### [at] abxartpl> wrote:

>Jerome, please look into settings of your news reader. You have answered to
>five years old message.

Oh drats, and I thought Dan was back :-/


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[ABX] Re: #system patch [8180 days 11 hours and 52 minutes ago]

Thu, 27 Nov 2003 14:45:38 GMT

On Thu, 27 Nov 2003 15:26:33 +0100, Le Forgeron <jgr### [at] freefr> wrote:
> It's also a can of worms for viral infection...
> I guess your next step will be to have an 'emacs'-like command 
> extension in the pov code, just to read the newsgroup in 
> pov-script...
>
> IMNSHO, "#system" is dangerous and unwanted.

Jerome, please look into settings of your news reader. You have answered to
five years old message.

ABX

[Le Forgeron] Re: #system patch [8180 days 12 hours and 11 minutes ago]

Thu, 27 Nov 2003 14:26:34 GMT

Dan Connelly a écrit:

> This is perhaps the simplest patch ever written,
> but is nevertheless of considerable power.  It is
> an implementation of a "#system" directive -- similar
> in syntax to the "#render" directive.  However,
> instead of writing the associated string to an
> output stream, it uses it as an argument to the
> C "system()" function.
> 
> The power is that code and/or image generators can be
> called from within POV scripts.  Even POV itself could
> be recursively called -- those "recursive art" images
> which are so popular can thus be fully specified within
> a single .pov file.
> 
> Other options include the calling of such external codes
> as torpatch or gforge from within POV.
> 
> Basically, it's a poor man's #macro, but with considerably
> extended capabilities.

It's also a can of worms for viral infection...
I guess your next step will be to have an 'emacs'-like command 
extension in the pov code, just to read the newsgroup in 
pov-script...

IMNSHO, "#system" is dangerous and unwanted.

[Pauly Man] Re: Macros that produce highly complex scenes [8249 days 17 hours and 37 minutes ago]

Fri, 19 Sep 2003 09:00:01 GMT

How about looking into modelling some complex systems. Try this link, it
might satisfy you:

htt://www.stephenwolfram.com/publications/articles/ca/

There you will find articles on what are called cellular automata, extremely
simple programs that can produce extremely complicated behaviour. It may
not be your kettle of fish, but at the very least it points out that to
rpoduce complexity doesn't require a complex algorithm or program.

Try some simple macro's, you may suprise yourself.

[Tom Galvin] Re: Windows commandline version with VC++ 6.0 Ho... [8288 days 22 hours and 4 minutes ago]

Mon, 11 Aug 2003 04:33:24 GMT

"Lonnie Cumberland" <Lon### [at] yahoocom> wrote in
news:web.3f3700837f47962cc8bfa9560@news.povray.org: 


> 
> Now I want to compile a version without the graphical interfave file
> so that it would be a commandline version.
> 
> Does someone know how to do this?
> 
> What is the process?
> 
> Cheers,
> Lonnie
> 
> 

This is not exactly what you were asking for, but it is a Cygwin command 
line version provided by Christoph Horman that runs under windows.  It may 
be helpful.

http://www-public.tu-bs.de:8080/~y0013390/povcyg/

If you are successful compiling a native windows version, I would be 
interested in your findings.  Just be sure to adhere to the POVLegal when 
you create your version.


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

[Lonnie Cumberland] Windows commandline version with VC++ 6.0 HowTo? [8289 days and 2 minutes ago]

Mon, 11 Aug 2003 02:35:01 GMT

Hello All,

I am new to PovRay and in particular to compiling up the sources. Recently I
was able to compile the sources for the latest version with my VC++ 6.0
compiler.

Now I want to compile a version without the graphical interfave file so that
it would be a commandline version.

Does someone know how to do this?

What is the process?

Cheers,
Lonnie

[tth] Re: ppm.cpp patch [8301 days and 42 minutes ago]

Wed, 30 Jul 2003 01:55:01 GMT

PoD wrote:
>I just looked at the code again, I'll change the code to skip all
>white space and comments.

  man ppm says that:

       - Whitespace (blanks, TABs, CRs, LFs).

[Apache] Re: Linux anyone [8318 days and 8 minutes ago]

Sun, 13 Jul 2003 02:29:24 GMT

www.imp.org, we're doing distributed raytracing using POV-Ray all the time
nowadays!

[Jim Barnes] Linux anyone [8329 days 13 hours and 36 minutes ago]

Tue, 1 Jul 2003 13:01:22 GMT

I will post this here and in the other programming newsgroup as I am not
sure which one gets more response and there is at this time only one message
in each of them.

I am looking for someone who has knowledge with regard to Linux and the
internal parsing of POV scenefiles prior to going to the tracer and want to
know if there is an implementation of POV for Linux that has only the tracer
in it.

I want to parse a scene file and then output the parsed parts to multiple
tracers as in the case of animation instead of each frame being genned by
the parser and then sent to the tracer I would like to parse the file and
send thirty frames to thirty tracers so i can produce thirty frames at once.

I could of course write a macro to handle all this in linux as I am sure
there is a variant of POV (from the early days) that would split a render
into parts. so that each part could be output as a TGA and then the lot
could be matched together in a graphics editor. That of course is the
tedious way and I am  not adverse to asking for help when i need to.

Anybody ?

TIA
jim### [at] linknetcomau

[Robin Davies] Re: Minimal Linux System [8332 days 22 hours and 24 minutes ago]

Sat, 28 Jun 2003 04:13:05 GMT

"Thomas Baier" <tho### [at] ibmnet> wrote in message
news:3676029F.B0404F15@ibm.net...
> Hi,
>
> is there a minimal Linux system available with console and gcc compiler
> for PC ?
>
> I want to provide my tools 3DWin and 3dto3d (file format convertors) for
> Linux.
>
>
> Thanks for your help.
>
> Thomas
>
> http://ourworld.compuserve.com/homepages/thbaier
>
>

Try cygwin. Not linux -- it runs natively under windows -- but it provides a
reasonable set of linux tools, and the gcc compiler compiles many (most?)
linux projects successfully.

www.cygwin.com

[Lutz-Peter Hooge] bicubic interpolation patch, rev.2 - bicubic_int... [8349 days 10 hours and 50 minutes ago]

Wed, 11 Jun 2003 15:47:08 GMT

Fixed a typo.

updated binary here:
<http://www.lutz-peter.hoogi.de/extern/bicubic_interp.zip>

[Lutz-Peter Hooge] bicubic interpolation patch - bicubic_interp_src... [8350 days 2 hours and 50 minutes ago]

Tue, 10 Jun 2003 23:47:49 GMT

Here is a ZIP with the changed (from MegaPov 1.0) source files.
A package including a win32 console executable is (temporary)
available here:
<http://www.lutz-peter.hoogi.de/extern/bicubic_interp.zip>

[ABX] Re: Are there one or more patches that do this? [8368 days 8 hours ago]

Fri, 23 May 2003 18:37:19 GMT

On Fri, 23 May 2003 13:32:24 EDT, "TheBB" <htk### [at] hotmalcom> wrote:
> - Change the color of a pixel either before or after anti aliasing.
> - Retrieve the color of a pixel either before or after anti aliasing.

Do you really need patched POV to do this ?
Just create another scene/animation with the same number of frames and then
start it over previous.

But perhaps no need for second queue ? Perhaps features in screen.inc include
file (locating texturized but semitransparent plane in front of camera) would be
enough ?

> - Automatically encode all produced bitmaps into an AVI or an MPEG video.
> Perhaps even with a sound file?

No need for it. There is enough of tools to make MPEGs and AVIs so that
programmers can work on real 3D features :-)

> Does anyone know of one or more patches that do this?

I suggest to post questions about patches into povray.unofficial.patches group
in the future.

ABX

[Christoph Hormann] Re: Are there one or more patches that do this? [8368 days 8 hours and 43 minutes ago]

Fri, 23 May 2003 17:53:54 GMT

TheBB wrote:
> 

First of all this is the wrong group for such questions.  This group is
for discussing things related to the POV-Ray source code, not for general
questions or feature requests.

> [...]
> 
> Ultimately, my need boils down to this:
> 
> - Change the color of a pixel either before or after anti aliasing.
> - Retrieve the color of a pixel either before or after anti aliasing.
> 
> And, if there is something that does it:
> 
> - Automatically encode all produced bitmaps into an AVI or an MPEG video.
> Perhaps even with a sound file?
> 
> Does anyone know of one or more patches that do this?

Both things are something not primarily a task for POV-Ray but for
external tools.  There are a lot of programs able to automatically process
a large number of images.  For example:

http://www.imagemagick.org/

Apart from that you seem to have a quite wrong idea on how antialiasing
works, there is no 'before and after' - you should have a look at the
corresponding part of the documentation concerning this.

For combining a number of images to an animation you can find various
tools in the POV-Ray link list:

http://www.povray.org/resources/links/3D_Animation_Utilities/

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

[TheBB] Are there one or more patches that do this? [8368 days 9 hours and 2 minutes ago]

Fri, 23 May 2003 17:35:01 GMT

Hey, I'm in the dire need of some simple post processing through POV files.
This is for animations, I could do all of this in - for example - PSP, but
I don't have the patience to go through more than 100 frames. So, having
some kind of limited post processing options availible directly in the POV
file would be really helpful for me at least.

Ultimately, my need boils down to this:

- Change the color of a pixel either before or after anti aliasing.
- Retrieve the color of a pixel either before or after anti aliasing.

And, if there is something that does it:

- Automatically encode all produced bitmaps into an AVI or an MPEG video.
Perhaps even with a sound file?

Does anyone know of one or more patches that do this?

Thanks.

[Christopher James Huff] Re: POV Memory [8382 days 5 hours and 14 minutes ago]

Fri, 9 May 2003 21:23:43 GMT

In article <3eaeff00$1@news.povray.org>,
 "Early Ehlinger" <ear### [at] respowercom> wrote:

> You could do a bounding-sphere at the beginning of each element.  The parser
> could then scan past the element quickly by checking open and close braces.
> It would store the center and radius of the element.  Determining if the
> element needs to be checked for ray collision is then simply a matter of
> comparing the distance from the center of the bounding-sphere to the ray
> with the radius of the bounding-sphere.  If it needs to be checked, the
> parser would go back and read the entire element.

This would require a bounding object to be specified for every object, 
and for the parser to save the entire text of each object associated 
with each bounds until it parses it, which will likely take more memory 
than the parsed object. This would just slow things down, eat up memory, 
and make things difficult for the user, as well as making the source 
code much more complex. And it adds yet another way for people to make 
mistakes, the manually specified bounding. POV originally used manual 
bounding, there's a reason it was automated.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

[Early Ehlinger] Re: POV Memory [8392 days 3 hours and 58 minutes ago]

Tue, 29 Apr 2003 22:38:56 GMT

"Christopher James Huff" <chr### [at] maccom> wrote:
> The only way to tell if part of the scene will be visible is to parse
> it. If you haven't parsed an object you have no information about it to
> judge visibility from. Some kind of progressive parsing where you parse
> some information, determine visibility, and conditionally continue
> parsing would be possible, but speedup would be minimal, and the
> description language would be barely human readable. The result would
> probably be much slower because of the work for determining if the
> object affects the final image.

You could do a bounding-sphere at the beginning of each element.  The parser
could then scan past the element quickly by checking open and close braces.
It would store the center and radius of the element.  Determining if the
element needs to be checked for ray collision is then simply a matter of
comparing the distance from the center of the bounding-sphere to the ray
with the radius of the bounding-sphere.  If it needs to be checked, the
parser would go back and read the entire element.

--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697
-- www.respower.com -- 500+ GHz Supercomputer Starting At USD$0.50/GHz*Hour

[Rick [Kitty5]] Re: Macros that produce highly complex scenes [8460 days 16 hours and 1 minute ago]

Thu, 20 Feb 2003 10:35:57 GMT

Peter Popov wrote:
> How about Gilles Tran's madpipe macro/include?

Thats what I ment!


--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

[Christopher James Huff] Re: Macros that produce highly complex scenes [8461 days 6 hours and 37 minutes ago]

Wed, 19 Feb 2003 20:00:28 GMT

In article <3e5272d6$1@news.povray.org>,
 "Michael Goldshteyn" <mgo### [at] n-o-s-p-a-m-earthlinknet> wrote:

> Does anyone know of any cool macros that produce generated scenes with an
> appearance of high complexity? I have seen several such macros that
> recursively build things. I am looking for ones I can use to generate very
> large (resolution) images containing many objects of different sizes. I want
> the images to appear VERY busy.

This group, povray.binaries.programming, is for binary postings that are 
related to programming, particularly things that deal with the POV-Ray 
source code such as patches. Your message belongs in a group like 
povray.general or povray.advanced-users.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

[Michael Goldshteyn] Re: Macros that produce highly complex scenes [8461 days 8 hours and 46 minutes ago]

Wed, 19 Feb 2003 17:51:03 GMT

Wow, that thing is amazing! Are there any other similar macros that produce
highly complex looking structures?

Thanks,

Mike

"Peter Popov" <pet### [at] vipbg> wrote in message
news:itq65v0pl2chlm8v70irjk4gr6ktdahbrp@4ax.com...
> How about Gilles Tran's madpipe macro/include?
>
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg

[Peter Popov] Re: Macros that produce highly complex scenes [8461 days 15 hours and 1 minute ago]

Wed, 19 Feb 2003 11:36:01 GMT

How about Gilles Tran's madpipe macro/include?


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[Rick [Kitty5]] Re: Macros that produce highly complex scenes [8461 days 17 hours and 3 minutes ago]

Wed, 19 Feb 2003 09:34:34 GMT

Michael Goldshteyn wrote:
> Does anyone know of any cool macros that produce generated scenes
> with an appearance of high complexity? I have seen several such
> macros that recursively build things. I am looking for ones I can use
> to generate very large (resolution) images containing many objects of
> different sizes. I want the images to appear VERY busy.

Wasnt there a pipe macro a while back - Ken?


--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

[ABX] Re: Macros that produce highly complex scenes [8462 days 8 hours and 35 minutes ago]

Tue, 18 Feb 2003 18:02:31 GMT

On Tue, 18 Feb 2003 11:52:16 -0600, "Michael Goldshteyn"
<mgo### [at] n-o-s-p-a-m-earthlinknet> wrote:
> Does anyone know of any cool macros that produce generated scenes with an
> appearance of high complexity? I have seen several such macros that
> recursively build things. I am looking for ones I can use to generate very
> large (resolution) images containing many objects of different sizes. I want
> the images to appear VERY busy.

I'm not sure why you are asking in this group but a few isosurfaces can be
enough.

ABX

[Michael Goldshteyn] Macros that produce highly complex scenes [8462 days 8 hours and 45 minutes ago]

Tue, 18 Feb 2003 17:52:22 GMT

Does anyone know of any cool macros that produce generated scenes with an
appearance of high complexity? I have seen several such macros that
recursively build things. I am looking for ones I can use to generate very
large (resolution) images containing many objects of different sizes. I want
the images to appear VERY busy.

Thanks,

Mike

[Christopher Endsley] Re: MPI patch for povray 3.5c [8466 days 20 hours and 54 minutes ago]

Fri, 14 Feb 2003 05:43:00 GMT

Matthias wrote:

> Hi folks,
> 
> based on PVMPOV, we have created a MPI patch for povray 3.5c It works
> quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and
> Irix.
> It works with the new automake/autoconf system of povray 3.5, so just
> unpack the archive to your povray directory and run './configure',
> 'make' and 'make install', nothing new for you guys ;-)
> It has statistics, options and other stuff, so try it out!!
> Requirements are povray3.5c and LAM/MPI 6.5.x
> What do you think about it??
> If you like it, I hope it can be added to the tools section on the
> povray homepage...
> 
> Matthias

How well does this intergrate with radiosity, photons, and other nifty
features of v3.5c? I'm going to try the InformationRod.pov from the images
group to try this out on 4 machines. Should I expect artifacts in the
rendering vs using a single CPU?
---Christopher

[Matthias] MPI patch for povray 3.5c [8476 days 3 hours and 34 minutes ago]

Tue, 4 Feb 2003 23:03:39 GMT

Hi folks,

based on PVMPOV, we have created a MPI patch for povray 3.5c It works 
quite well and has been tested on Linux (SuSE 7.3&8.0), Solaris 8.0 and 
Irix.
It works with the new automake/autoconf system of povray 3.5, so just 
unpack the archive to your povray directory and run './configure', 
'make' and 'make install', nothing new for you guys ;-)
It has statistics, options and other stuff, so try it out!!
Requirements are povray3.5c and LAM/MPI 6.5.x
What do you think about it??
If you like it, I hope it can be added to the tools section on the 
povray homepage...

Matthias

[PoD] Re: ppm.cpp patch [8486 days 12 hours and 48 minutes ago]

Sat, 25 Jan 2003 13:49:05 GMT

I just looked at the code again, I'll change the code to skip all
white space and comments.

[PoD] Re: ppm.cpp patch [8486 days 12 hours and 54 minutes ago]

Sat, 25 Jan 2003 13:43:45 GMT

On Sat, 25 Jan 2003 13:30:59 +0100, Christoph Hormann wrote:

> 
> 
> PoD wrote:
>> 
>> As reported in p.g, POV-Ray 3.5 does not read PPM files properly. The
>> proper format is
>> P6
>> width height
>> max_value
>> data
>> 
>> 
> Just for the record, the only rule for spacing in the header of a ppm is
> that between the values there is one or more whitespace (before the data
> in binary ppm's only one whitespace is allowed).

But most if not all PPMs use the above format, possibly with comments as
well.

> 
> Concerning your patch - i have not tested it but i never had problems
> reading ppm's with POV-Ray.
> 

That's odd because the ppm code in 3.5a does not read normal PPM files.

[Christoph Hormann] Re: ppm.cpp patch [8486 days 14 hours and 6 minutes ago]

Sat, 25 Jan 2003 12:30:59 GMT

PoD wrote:
> 
> As reported in p.g, POV-Ray 3.5 does not read PPM files properly.
> The proper format is
> P6
> width height
> max_value
> data
> 

Just for the record, the only rule for spacing in the header of a ppm is
that between the values there is one or more whitespace (before the data
in binary ppm's only one whitespace is allowed).

Concerning your patch - i have not tested it but i never had problems
reading ppm's with POV-Ray.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

[PoD] ppm.cpp patch [8486 days 14 hours and 18 minutes ago]

Sat, 25 Jan 2003 12:19:04 GMT

As reported in p.g, POV-Ray 3.5 does not read PPM files properly.
The proper format is
P6
width height
max_value
data

The POV reader expects the max_value on the same line as the width and 
height.  If you don't want to patch POV-Ray, you can edit the PPM files 
to make them work in POV.

Here's a patch to fix it. I only spent a short time on this, so it's 
probably still broken but it loads the files that I've tried.

-- 
PoD.

[Massimo Valentini] Re: sphere_sweep, lathe and blob optimization. [8515 days 16 hours and 46 minutes ago]

Fri, 27 Dec 2002 09:50:52 GMT

"Massimo Valentini" ha scritto
: Attached's the patch mentioned in povray.programming in the thread with
: the same subject
: 

As requested here is a gzipped tar of the whole files affected.

Hope that unzipping and untarring isn't considered hard work.

Massimo

[Massimo Valentini] sphere_sweep, lathe and blob optimization. [8516 days 6 hours and 16 minutes ago]

Thu, 26 Dec 2002 20:21:16 GMT

Attached's the patch mentioned in povray.programming in the thread with
the same subject

Massimo

[Christopher James Huff] Re: POV Memory [8535 days and 59 minutes ago]

Sun, 8 Dec 2002 01:38:19 GMT

In article <3df2960d@news.povray.org>,
 "Apache" <apa### [at] yahoocom> wrote:

> Hey, that's very interesting stuff. I was thinking about some kind of JIP
> (Just In time Parsing) for POV-Ray. (I have been scanning and browsing
> through the source code today.) Only those parts of the scene that get
> intersected by rays should be parsed. But this will only pay off with really
> huge scenes with very large amounts of complex csg objects or other bounded
> objects.

The only way to tell if part of the scene will be visible is to parse 
it. If you haven't parsed an object you have no information about it to 
judge visibility from. Some kind of progressive parsing where you parse 
some information, determine visibility, and conditionally continue 
parsing would be possible, but speedup would be minimal, and the 
description language would be barely human readable. The result would 
probably be much slower because of the work for determining if the 
object affects the final image.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

[Apache] Re: POV Memory [8535 days 1 hour and 52 minutes ago]

Sun, 8 Dec 2002 00:45:01 GMT

Hey, that's very interesting stuff. I was thinking about some kind of JIP
(Just In time Parsing) for POV-Ray. (I have been scanning and browsing
through the source code today.) Only those parts of the scene that get
intersected by rays should be parsed. But this will only pay off with really
huge scenes with very large amounts of complex csg objects or other bounded
objects.

"Vahur Krouverk" <vkr### [at] comtradeee> wrote in message
news:3C7### [at] comtradeee...
> majucatur wrote:
> > Hi.
> >
> >    I have a question for you, well, I'm developing a ray-tracing program
and
> > I need help with the aspect of the memory allocation. I define my
objects in
> > special structures, each object is allocated in memory dynamically, you
> > know, with memalloc and free, but the question is: How can I optimize
this?,
> > I want to use the less memory possible, because with objects like mesh
or
> > series of thousand objects consumes a lot of RAM memory, I don't know
how
> > POV-Ray uses the memory to its objects, but certainly it can trace
scenes
> > with a lot of complex objects without problem...
> >
> >    Should I put everything in memory?, primitives, mesh, textures, etc.
or
> > exist a technique to use more efficiently my resources.
> If you want to render more geometry than fits into memory, then only
> option is to cache it (if you don't want to leave it to op. sys.
swapping).
> One paper I know about it could be found:
> http://graphics.stanford.edu/papers/displace/
> Google should help in finding similar papers.
> Other option is to optimize geometry. Latest Siggraph papers ('00 IIRC)
> have number of various optimizations described.
>
>
>

[Massimo Valentini] Several blob bugs (job000189) [2] [8570 days 8 hours and 27 minutes ago]

Sat, 2 Nov 2002 18:10:11 GMT

For details see the thread with the same subject on povray.programming

Massimo

[Christopher James Huff] G - g.tgz (1/1) [8576 days 3 hours and 56 minutes ago]

Sun, 27 Oct 2002 22:41:00 GMT

[Theo Gottwald *] Re: POVRAY-Rendering in networks? [8615 days 16 hours and 15 minutes ago]

Wed, 18 Sep 2002 10:22:34 GMT

Use ... (see below).

--Theo

----------------------------------------------------------------------------
---------------------------------
Distributed Network-Rendering or Local SMP-Rendering on all CPU's you have.
With SMPOV und POV-Ray 3.5.Download free at:
http://www.it-berater.org/smpov.htm

[Le Forgeron] model of a scene [8660 days 11 hours and 55 minutes ago]

Sun, 4 Aug 2002 14:42:13 GMT

Seems to be the right group, at least I hope so.

I had too much time waiting for the 3.5, so I played with 3.1 ...

I tried to represent a scene with some UML goodies (not strictly sticking to the
standard), and I'm wondering if it wouldn't be better to replace the layered_texture
(in Cyan in the picture) with a layered_pigment (in Green), because it is rather
how it works in reality.

Also, it's seems that a patterned_finish is somehow missing, even if it can currently
be done using the patterned_texture. (The green part attached to the finish does
not exist).
Wouldn't it be simpler to restrict the control at the lowest level, or
is there a real gain to also have a patterned_texture ?

Any thought on these ?
Any interest ?
Is there any one reading ?

P.S.: Do not pay attention to the yellow tags, they are just the parts which
are the most likely to get extensions whenever someone make a patch.
-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

[Philippe Lhoste] Re: command line [8683 days 11 hours and 21 minutes ago]

Fri, 12 Jul 2002 15:16:33 GMT

"majucatur" <maj### [at] yahoocom> wrote:
> Another example:
>
> program.c - - - - -
>
> #include <math.h>
> #include <stdio.h>
>
> void main() {
>    float Var;
>    printf("\nA number :");
>    scanf("%f", Var);
>    printf("\n\nThe square root of %f is %f\n", Var, sqrt(Var));
>    getch();
> }
>
> - - - - -
>
> that's all, how can I compile this in the command line?

Ouch, it is off topic (since it will compile) but your program shows a very
common mistake:
scanf("%f", Var); should be scanf("%f", &Var); ie. you must give it the
address of the variable.

--
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--

[Martial] Re: command line [8735 days 10 hours and 2 minutes ago]

Tue, 21 May 2002 16:35:37 GMT

pardon for my english !
I use Borland55 free command line ! 

the doc Readme
1- . Run freecommandlinetools.exe; choose the 
   drive and folder into which you want to
   install the free C++Builder 5 command line 
   tool development system.
   
2. From the bin directory of your installation:
   a. Add "c:\Borland\Bcc55" 
           to the existing path
   b. Create a bcc32.cfg file which will set 
      t he compiler options for the Include 
       and Lib paths (-I and -L switches to 
       compiler) by adding these lines:

      -I"c:\Borland\Bcc55\include"
      -L"c:\Borland\Bcc55\lib"

   c. Create an ilink32.cfg file which will set 
      the linker option for the Lib path by 
      adding this line:

      -L"c:\Borland\Bcc55\lib"



I try your mini program it's good !

--
Martial

[Fred Rathke] Re: German developers group available [8791 days 11 hours and 23 minutes ago]

Tue, 26 Mar 2002 15:13:54 GMT

T h r e a d   i s   c l o s e d .

We will go on in the newsgroup povray.programming
subject: "Anything made percetable"

Sorry for the inconvenience and thanks for your understanding.

--

Sincerely yours

Fred Rathke
ComRat - Communication Rational
60316 Frankfurt
Germany

[Fred Rathke] Re: German developers group available [8791 days 11 hours and 36 minutes ago]

Tue, 26 Mar 2002 15:01:10 GMT

Hi,     Sorry if I should have been OT. I think I am still in the
right NG, because it could be of interest for some of the programers
in here, too.

If hope PovRay is able to work automatically when some scripts run. So
the simulation that will deliver the datas will feed PovRay and PovRay
will generate the pictures. All this will be put online automatically
in the format: video, and/or HTML animated gifs or VRML(?) or or or
... - The view of the virtual eyes in the simulation can be set on the
internet by anybody...

Doesnt all this sound like programer's stuff? :-)

SDL and POV export I dont know, sorry.

--
Sincerely yours

Fred Rathke
ComRat - Communication Rational
60316 Frankfurt
Germany

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> schrieb im Newsbeitrag
news:o001au8uje5dcdqfrl9sbntblrkrbpvkph@4ax.com...
On Tue, 26 Mar 2002 14:58:52 +0100, "Fred Rathke" <com### [at] hotmailcom>
wrote:
> I would like to write a program that is able to convert any datas to
> something perceptible. Sounds/light/objects to symbols, curves,
> frequenzes of light, or sounds.

It sounds too general for me. Or I don't understand this idea.

Why you are writing about it here, in POV related server. Do you plan
to write
it in SDL. Such a difficoult task should be rather done in more
efficient
language/programming tool. Or do you plan POV export ?

(btw. this is binary group, programming discuusion should be rather
placed in
povray.programming group - corrected in followup-to)

ABX

[Fred Rathke] Re: German developers group available [8791 days 12 hours and 38 minutes ago]

Tue, 26 Mar 2002 13:58:58 GMT

Hi Ron, hi all,

There is a little project on my mind:
I would like to write a program that is able to convert any datas to
something perceptible. Sounds/light/objects to symbols, curves,
frequenzes of light, or sounds. Any combination shall be set in a
config file or with a GUI, or HTML-form later.

I would appreciate it a lot if some of you guys would like to take
part of my brainstorming, specially if you could speak German with me,
sorry. If they understand natural science a bit (it is my hobby only)
it would be much easier for all of us. We philosophy first, I hope you
dont mind.

If there are other project or applications which tried it already I
would like to get some links about it, or even some words for my
google. Even theoretical work or articles about it could be of use.
For the first - thanks a lot to all of you.

--
Sincerely yours

Fred Rathke
ComRat - Communication Rational
60316 Frankfurt
Germany

[Ron Parker] Re: German developers group available [8805 days 5 hours and 56 minutes ago]

Tue, 12 Mar 2002 20:41:33 GMT

On Tue, 12 Mar 2002 21:16:38 +0100, Fred Rathke wrote:
> For some very special questions I would like to meet some German
> speaking programmers working on povray (and in touch with the
> coordinators of the whole project). Otherwise I will have to have my
> English dictionary at hand all the time *sigh ;-) Thanks.

What is the general nature of your questions, so you can get in touch with 
the right people?

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

[Fred Rathke] Re: German developers group available [8805 days 5 hours and 58 minutes ago]

Tue, 12 Mar 2002 20:38:54 GMT

These groups I found already:
<A
HREF="news://news.povray.org/povray.international">povray.internationa
l</A>
<BR><A
HREF="news://news.povray.org/povray.international.binaries">povray.int
ernational.binaries</A>

German posts start with [de]. But your help I still need. Thanks.

--
Sincerely yours

Fred Rathke
ComRat - Communication Rational
60316 Frankfurt
Germany

[Fred Rathke] German developers group available [8805 days 6 hours and 20 minutes ago]

Tue, 12 Mar 2002 20:16:50 GMT

For some very special questions I would like to meet some German
speaking programmers working on povray (and in touch with the
coordinators of the whole project). Otherwise I will have to have my
English dictionary at hand all the time *sigh ;-) Thanks.

Hopefully ....

--
Sincerely yours

Fred Rathke
ComRat - Communication Rational
60316 Frankfurt
Germany

[Fred Rathke] What are the limits? [8805 days 6 hours and 30 minutes ago]

Tue, 12 Mar 2002 20:07:11 GMT

Do you know where to find a table of limits of this and ofter
raytracing programs? Thanks a lot.

--
Sincerely yours

Fred Rathke
ComRat - Communication Rational
60316 Frankfurt
Germany

[Halbert] Re: command line [8808 days 22 hours and 52 minutes ago]

Sat, 9 Mar 2002 03:45:07 GMT

"majucatur" <maj### [at] yahoocom> wrote in message
news:3c8504b5@news.povray.org...
> Another example:
>
> program.c - - - - -
>
> #include <math.h>
> #include <stdio.h>
>
> void main() {
>    float Var;
>    printf("\nA number :");
>    scanf("%f", Var);
>    printf("\n\nThe square root of %f is %f\n", Var, sqrt(Var));
>    getch();
> }
>
> - - - - -
>
> that's all, how can I compile this in the command line?
>

I used Borland C++ from 1994-1997
Try:

tcc -ms program.c -oprogram.obj

Long ago when I used Borland C++ there was also command line options to use
floating point emulation (the default) and another to use the x87 library. I
don't know if such is the case with newer versions (that is how long it has
been since I used the Borland compilers.) -f87 for 8087 and -f287 for 80287.
This would precede the input file name.

After you compile and have the .obj(s) then you need to link it. When
I used the compilers, I had to use a memory model.

c0t.obj    tiny model(used for things like .com files. The program segment
prefix (PSP) is different for this model and there is no stack segment)
c0s.obj    for small model (appropriate for the source given.)
c0c.obj    for compact
c0m.obj    for medium
c0l.obj for large
c0h.obj    for huge

The linker that came with Borland was tlink.

tlink  /c  \Borlandc\lib\c0s program, program,,\borlandc\lib\maths
\borlandc\lib\cs

The /c makes the symbols case sensitive. the next two items are the .obj
files for this compile. First the small version standard c startup module
(along with the path)  then the program.obj we compiled before. the next
item is the output executable: program.exe. the ommited option is for a map
file. Last are the two small version libraries used: maths.lib for the sqrt
function, then cs the small version standard c library.

Keep in mind that I seldom use command line compilers these days and it has
been years since I've used Borland. Let me know if my take on dos-mode
command line compilers is too medieval. I hope this is at least partly
useful. I have the documentation around here somewhere in a box. If I find
it I will scan the relevent sections for you.

H²

[] Re: POV Memory [8811 days 18 hours and 36 minutes ago]

Wed, 6 Mar 2002 08:00:54 GMT

>   But as the original claim was that six floats is enough, that would only
> make an axis-aligned box, which is rather limiting.

You are right, I missed typing the "at least".
So you won. :)

[Warp] Re: command line [8812 days 4 hours and 27 minutes ago]

Tue, 5 Mar 2002 22:09:50 GMT

I think that your problem is specific to the compiler you are using (it's
not seeing the standard include files for some reason). Only a person
familiar with that compiler can give a precise answer.
  It sounds strange, though (usually you don't need to do anything special
for the compiler to see its own include files).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Warp] Re: POV Memory [8812 days 4 hours and 29 minutes ago]

Tue, 5 Mar 2002 22:08:03 GMT

"Jürgen Scharfy" <sch### [at] surfeuat> wrote:
> in this case you have to count the transformations to the box.

  But as the original claim was that six floats is enough, that would only
make an axis-aligned box, which is rather limiting.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[majucatur] RE: command line [8812 days 8 hours and 50 minutes ago]

Tue, 5 Mar 2002 17:47:33 GMT

Another example:

program.c - - - - -

#include <math.h>
#include <stdio.h>

void main() {
   float Var;
   printf("\nA number :");
   scanf("%f", Var);
   printf("\n\nThe square root of %f is %f\n", Var, sqrt(Var));
   getch();
}

- - - - -

that's all, how can I compile this in the command line?

[Apache] Re: command line [8812 days 12 hours and 28 minutes ago]

Tue, 5 Mar 2002 14:08:53 GMT

Hey man! I completely forgot about that. Thanks! I hate scrolling through
those .h files all the time to find out how I did those funky structs....


--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

[] Re: POV Memory [8812 days 12 hours and 38 minutes ago]

Tue, 5 Mar 2002 13:59:45 GMT

>   Thinking about it, it actually doesn't need any floats at all. Just
> create a unit-cube by default and let the transformations do the rest.
>   So in fact it requires 0 floats.


So you need no memory at all since all is done in the transformations. just
few bytes to distinguish between a base-sphere, a base-box, a base-cone
.....
the most complex scene only needs few bytes then.

For the same reason we can recursively compress a file until it is 1bit in
size (which is the information -the file is there-).

regards
SY

[] Re: POV Memory [8812 days 12 hours and 43 minutes ago]

Tue, 5 Mar 2002 13:54:43 GMT

>   I assumed that we can apply a transformation matrix to any object,
including
> the box.

in this case you have to count the transformations to the box.

[Ron Parker] Re: POV Memory [8812 days 13 hours and 16 minutes ago]

Tue, 5 Mar 2002 13:20:55 GMT

On 5 Mar 2002 06:53:17 -0500, Warp wrote:
> Ron Parker <ron### [at] povrayorg> wrote:
>> floats or vectors?
> 
>   Floats. (Of course that will create a cube, but as I said, transformations
> can make it a box of any shape, and place and orient it in any way.)
> 
>   Thinking about it, it actually doesn't need any floats at all. Just
> create a unit-cube by default and let the transformations do the rest.
>   So in fact it requires 0 floats.

Yeah, but then we'd accuse you of being a Moray sympathizer.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

[Warp] Re: command line [8812 days 14 hours and 37 minutes ago]

Tue, 5 Mar 2002 12:00:38 GMT

majucatur <maj### [at] yahoocom> wrote:
> I know that I need to write a .c module with functions, and a .h file with
> its data types and global definitions.

  Why is it a so common misconception that you should put all the data types
of a .c file into its correspondent .h file?
  A .c file is a module, and its correspondent .h file declares its
*public interface*, that is, it declares the part of the module which other
modules need to see.
  Internal data types (and functions) used by the module are *not* part of
this public interface. Also global variables used solely in this module (even
though we don't use global variables, do we?) should be declared as static in
the .c file, not in the .h file. The .h file should always be as minimal as
possible.

  As for your actual question, I didn't understand it well enough to write
a proper answer.
  (Perhaps a really short example could help?)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[Warp] Re: POV Memory [8812 days 14 hours and 43 minutes ago]

Tue, 5 Mar 2002 11:54:00 GMT

"Jürgen Scharfy" <sch### [at] surfeuat> wrote:
> how do you define a box with 2 floats? even length, height and depth would
> already need 3!

  I assumed that we can apply a transformation matrix to any object, including
the box.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Warp] Re: POV Memory [8812 days 14 hours and 44 minutes ago]

Tue, 5 Mar 2002 11:53:17 GMT

Ron Parker <ron### [at] povrayorg> wrote:
> floats or vectors?

  Floats. (Of course that will create a cube, but as I said, transformations
can make it a box of any shape, and place and orient it in any way.)

  Thinking about it, it actually doesn't need any floats at all. Just
create a unit-cube by default and let the transformations do the rest.
  So in fact it requires 0 floats.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[] Re: POV Memory [8812 days 18 hours and 8 minutes ago]

Tue, 5 Mar 2002 08:29:31 GMT

>   In fact, 2 is enough. See the box syntax for an example. (Of course with
> 2 floats it's axis-aligned, but that doesn't matter; the transformations
of
> a box are not made by moving its vertices anyways.)


how do you define a box with 2 floats? even length, height and depth would
already need 3!
regards
SY

[majucatur] command line [8812 days 21 hours and 3 minutes ago]

Tue, 5 Mar 2002 05:34:46 GMT

Hi

I have a little problem, well, I can't include the standard libraries in my
C project, I'm using the compiler TCC of Borland, now Free :) but without
documentation :( I can't compile a program properly. I was reading that I
need to specify some things different for standard libraries, I don´t know
how to do this. This should be very easy for some people here, because
POV-Ray requires to be compiled in this way. If someone could explain me the
way to compile a module-project correctly, and how to link the .obj files
when I finish.

I know that I need to write a .c module with functions, and a .h file with
its data types and global definitions. I need also a main file which
contains the function main() I suppose that I need compile the modules
first, and then the main file which uses the other modules. But when I use
libraries like math, it can't be compiled and tcc finish with a error
message explaining this.

Can somebody help me with this problem?

Thanks a lot.

[Ron Parker] Re: POV Memory [8813 days and 26 minutes ago]

Tue, 5 Mar 2002 02:10:54 GMT

On 4 Mar 2002 11:52:27 -0500, Warp wrote:
> "Jürgen Scharfy" <sch### [at] surfeuat> wrote:
>> IMHO a box needs 6 float parameters to be defined...
> 
>   In fact, 2 is enough. See the box syntax for an example. (Of course with
> 2 floats it's axis-aligned, but that doesn't matter; the transformations of
> a box are not made by moving its vertices anyways.)

floats or vectors?

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

[Warp] Re: POV Memory [8813 days 9 hours and 45 minutes ago]

Mon, 4 Mar 2002 16:52:27 GMT

"Jürgen Scharfy" <sch### [at] surfeuat> wrote:
> IMHO a box needs 6 float parameters to be defined...

  In fact, 2 is enough. See the box syntax for an example. (Of course with
2 floats it's axis-aligned, but that doesn't matter; the transformations of
a box are not made by moving its vertices anyways.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[] Re: POV Memory [8813 days 10 hours and 39 minutes ago]

Mon, 4 Mar 2002 15:57:54 GMT

> box          24 bytes

so you use only 4 bytes for the float number storage?
IMHO a box needs 6 float parameters to be defined...
regards
SY

[Warp] Re: POV Memory [8822 days 8 hours and 12 minutes ago]

Sat, 23 Feb 2002 18:25:19 GMT

majucatur <maj### [at] yahoocom> wrote:
> sphere needs 3 coordinates for the center and a radius, each variable takes
> 4 bytes of memory, well, I need 16 bytes for a sphere, but for a box I need
> 24 bytes...

  So in 10 Megs of memory you can store almost 437000 boxes. I don't see
the problem.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[Vahur Krouverk] Re: POV Memory [8823 days 1 hour and 38 minutes ago]

Sat, 23 Feb 2002 00:58:55 GMT

majucatur wrote:
> Hi.
> 
>    I have a question for you, well, I'm developing a ray-tracing program and
> I need help with the aspect of the memory allocation. I define my objects in
> special structures, each object is allocated in memory dynamically, you
> know, with memalloc and free, but the question is: How can I optimize this?,
> I want to use the less memory possible, because with objects like mesh or
> series of thousand objects consumes a lot of RAM memory, I don't know how
> POV-Ray uses the memory to its objects, but certainly it can trace scenes
> with a lot of complex objects without problem...
> 
>    Should I put everything in memory?, primitives, mesh, textures, etc. or
> exist a technique to use more efficiently my resources.
If you want to render more geometry than fits into memory, then only
option is to cache it (if you don't want to leave it to op. sys. swapping).
One paper I know about it could be found:
http://graphics.stanford.edu/papers/displace/
Google should help in finding similar papers.
Other option is to optimize geometry. Latest Siggraph papers ('00 IIRC) 
have number of various optimizations described.

[majucatur] RE: POV Memory [8823 days 8 hours and 27 minutes ago]

Fri, 22 Feb 2002 18:09:57 GMT

Sorry, malloc is the function, I'm writting my program in C, but what I want
to know is the Algorithm or procedure to distribute the memory, for example:

sphere needs 3 coordinates for the center and a radius, each variable takes
4 bytes of memory, well, I need 16 bytes for a sphere, but for a box I need
24 bytes...

sphere    16 bytes
box          24 bytes
cone        28 bytes
cylinder   28 bytes
plane       16 bytes
torus          8 bytes

this are without transformations, they need more memory, that's the problem,
my memori not is infinite

[Warp] Re: POV Memory [8823 days 18 hours and 33 minutes ago]

Fri, 22 Feb 2002 08:04:40 GMT

You didn't mention the programming language you are using ('memalloc' is
not a C nor C++ function; at least not a standard one).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[majucatur] POV Memory [8824 days 4 hours and 46 minutes ago]

Thu, 21 Feb 2002 21:51:22 GMT

Hi.

   I have a question for you, well, I'm developing a ray-tracing program and
I need help with the aspect of the memory allocation. I define my objects in
special structures, each object is allocated in memory dynamically, you
know, with memalloc and free, but the question is: How can I optimize this?,
I want to use the less memory possible, because with objects like mesh or
series of thousand objects consumes a lot of RAM memory, I don't know how
POV-Ray uses the memory to its objects, but certainly it can trace scenes
with a lot of complex objects without problem...

   Should I put everything in memory?, primitives, mesh, textures, etc. or
exist a technique to use more efficiently my resources.

Thanks for your time and patience.

[Tor Olav Kristensen] Re: torus equation [8834 days 1 hour and 59 minutes ago]

Tue, 12 Feb 2002 00:38:10 GMT

majucatur wrote:
> 
> Thank you to Peter Popov and Ron Parker for the information that you gave me
> on CSG, that were of great utility.
> 
> I have another question, does somebody know how is expressed a torus
> mathematically?, the other figures don't represent a real problem, but does
> it seem that the torus is a compound figure, how can I calculate the normal,
> the intersections, etc. for a torus?, does exist a torus mathematical
> formula?...

For answers to some of your questions, you
may have a look into these posts of mine:

http://news.povray.org/povray.advanced-users/20922/138919
news://news.povray.org/3C292BC5.5A6AB4A6%40hotmail.com

http://news.povray.org/povray.advanced-users/20922/145305
news://news.povray.org/3C4B045F.DFBD5D79%40hotmail.com


And at this page you'll find a polynomial
equation for the torus:

http://www.nada.kth.se/hacks/doc/PoVRay/pov122.html


Here's a macro that will return a quartic torus:

#macro QuarticTorus(Rmaj, Rmin)

  #local rxz = -2*(Rmaj^2 + Rmin^2);
  #local ry =  2*(Rmaj^2 - Rmin^2);
  #local rr =  (Rmaj^2 - Rmin^2)^2;

  quartic {
    <
      1,   0,   0,   0,   2,   0,   0,   2,   0, rxz,
      0,   0,   0,   0,   0,   0,   0,   0,   0,   0,
      1,   0,   0,   2,   0,  ry,   0,   0,   0,   0,
      1,   0, rxz,   0,  rr
    >
    sturm
  }

#end // macro QuarticTorus


Tor Olav

[Warp] Re: torus equation [8843 days 16 hours and 30 minutes ago]

Sat, 2 Feb 2002 10:07:41 GMT

majucatur <maj### [at] yahoocom> wrote:
: does exist a torus mathematical formula?...

  The torus function is:

sqrt((sqrt(x^2+z^2)-Rmaj)^2 + y^2) - Rmin = 0

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

[majucatur] torus equation [8844 days 9 hours and 41 minutes ago]

Fri, 1 Feb 2002 16:56:48 GMT

Thank you to Peter Popov and Ron Parker for the information that you gave me
on CSG, that were of great utility.

I have another question, does somebody know how is expressed a torus
mathematically?, the other figures don't represent a real problem, but does
it seem that the torus is a compound figure, how can I calculate the normal,
the intersections, etc. for a torus?, does exist a torus mathematical
formula?...

Again, thank you for your time.

[Warp] Re: [C++] Question about reinterpret_cast<> [8844 days 13 hours and 52 minutes ago]

Fri, 1 Feb 2002 12:45:15 GMT

Tim Chan <tim### [at] blueyondercouk> wrote:
: #include <iostream>
: using namespace std;
: const int sz = 100;

: struct X { int a[sz]; };

: void print(X* x) {
:   for(int i = 0; i < sz; i++)
:     cout << x->a[i] << ' ';
:   cout << endl << "--------------------" << endl;
: }

: int main() {
:   X x;
:   print(&x);

:   int* xp = reinterpret_cast<int*>(&x);

:   for(int* i = xp; i < xp + sz; i++)
:     *i = 0;

:   print(reinterpret_cast<X*>(xp));

: } ///:~

  I know I'm replying to a rather old message, but this code looked so
horrible, that I must reply.
  Firstly I think that it breaks the standard. One cannot assume that
the member variables of a struct start right at the beginning of the
struct.
  Secondly, why not just:

int main() {
  X x;
  print(&x);

  for(int i = 0; i < sz; ++i)
    x.a[i] = 0;

  print(&x);
}

  It's a lot nicer, doesn't use hacks and doesn't break the standard.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

[Peter Popov] Re: CSG algorithms [8846 days 4 hours and 6 minutes ago]

Wed, 30 Jan 2002 22:31:31 GMT

On 29 Jan 2002 19:02:36 -0500, Ron Parker <ron### [at] povrayorg>
wrote:

>You don't need a Normal_At(Point) method if you instead compute and save
>the normal when you retrieve the intersection; for some objects this is less
>time-consuming and less ambiguous.

OK, OK, but for some it is not. Maybe something like:

#define Returned_Normal N

if ((!N.x) && (!N.y) && (!N.z) )
  N = ThisObject.Normal_At(Intersection_Point);

You know, I never thought of it this way - that by the maths of it,
some objects will readily provide the normal while intersection
testing. Now there's something to wake me up :)

Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[Ron Parker] Re: CSG algorithms [8847 days 2 hours and 35 minutes ago]

Wed, 30 Jan 2002 00:02:36 GMT

On Wed, 30 Jan 2002 01:11:40 +0200, Peter Popov wrote:
> For this to work, all objects should have an Inside(Point) method, an
> All_Intersections(Ray) method and a Normal_At(Point) method, or the
> equivalent functionality in the language you're coding in.

You don't need a Normal_At(Point) method if you instead compute and save
the normal when you retrieve the intersection; for some objects this is less
time-consuming and less ambiguous.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

[Peter Popov] Re: CSG algorithms [8847 days 3 hours and 23 minutes ago]

Tue, 29 Jan 2002 23:14:04 GMT

On Tue, 29 Jan 2002 16:04:39 -0600, "majucatur" <maj### [at] yahoocom>
wrote:

>I have a little problem, Someone knows how the CSG works?, mathematically, I
>am interested in the algorithm that determine what object is product of the
>CSG construction and how can I develop a CSG raytracing system. I was
>"reading" the POV sourde files, but with all that modules i got confused.

Simple. Get all ray-shape intersections from all objects in the CSG,
depth-sort them, then get the first one that is contained inside all
objects of the CSG except the one it belongs to. That's your
intersection point with the CSG. The normal at this point is the
normal of the object the intersection belongs to, flipped if
necessary.

For this to work, all objects should have an Inside(Point) method, an
All_Intersections(Ray) method and a Normal_At(Point) method, or the
equivalent functionality in the language you're coding in.

Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[majucatur] CSG algorithms [8847 days 4 hours and 31 minutes ago]

Tue, 29 Jan 2002 22:06:49 GMT

Hello.

I have a little problem, Someone knows how the CSG works?, mathematically, I
am interested in the algorithm that determine what object is product of the
CSG construction and how can I develop a CSG raytracing system. I was
"reading" the POV sourde files, but with all that modules i got confused.

Thanks for your time.

[Chris Jeppesen] Compiling Megapov 0.7 for Linux patch [8852 days and 20 minutes ago]

Fri, 25 Jan 2002 02:17:16 GMT

This is a patch for compiling Megapov 0.7 on Linux. Read how to install 
it in povray.unix

[Mark Wagner] Re: POVRay Parser [8864 days 20 hours and 48 minutes ago]

Sat, 12 Jan 2002 05:49:12 GMT

John D. Gwinner wrote in message <3c30da6c$1@news.povray.org>...
>Thanks - I'm working on a physics package (complete) for POVRay
animations -
>ideally, I'd have to read in the scene file even if much of it isn't
>'understood'.
>
>Do you know if there is a consolidated BNF / Grammer version?  I could hack
>that into a YACC/BISON version ...


I don't think so.  I think the only description of the POV syntax is the one
scattered throughout the POV documentation.

--
Mark

[John D Gwinner] Re: POVRay Parser [8876 days 5 hours and 1 minute ago]

Mon, 31 Dec 2001 21:36:44 GMT

Thanks - I'm working on a physics package (complete) for POVRay animations -
ideally, I'd have to read in the scene file even if much of it isn't
'understood'.

Do you know if there is a consolidated BNF / Grammer version?  I could hack
that into a YACC/BISON version ...

                  == John ==

"Mark Wagner" <mar### [at] gtenet> wrote in message
news:3c204483@news.povray.org...
>
> John D. Gwinner wrote in message <3c1f8de7$1@news.povray.org>...
> >Does anyone have a good generalized POV-Ray parser?
> >
>
>
> The only generalized POV-Ray parser that exists is POV-Ray itself.  I
think
> there's a parser for the 2.2 syntax, and there are parsers for subsets of
> the mesh and mesh2 syntax, but that's it.
>
> --
> Mark
>
>

[Mark Wagner] Re: POVRay Parser [8888 days 18 hours and 56 minutes ago]

Wed, 19 Dec 2001 07:40:51 GMT

John D. Gwinner wrote in message <3c1f8de7$1@news.povray.org>...
>Does anyone have a good generalized POV-Ray parser?
>


The only generalized POV-Ray parser that exists is POV-Ray itself.  I think
there's a parser for the 2.2 syntax, and there are parsers for subsets of
the mesh and mesh2 syntax, but that's it.

--
Mark

[John D Gwinner] POVRay Parser [8889 days 7 hours and 56 minutes ago]

Tue, 18 Dec 2001 18:41:43 GMT

Does anyone have a good generalized POV-Ray parser?

I'm working on adding physics and collision detection to POV-Ray, and I need
to read in the scene to preprocess it - see the conversation in
povray.general for more info ..

                  == John ==

[Tor Olav Kristensen] Re: matrices.c [8903 days 1 hour and 52 minutes ago]

Wed, 5 Dec 2001 00:45:33 GMT

Jérôme Grimbert wrote:
>...
> Tor Olav Kristensen wrote:
> >...
> > Jérôme Grimbert wrote:
> > >...
> > > If you were trying to get some significant speed improvement, I'm afraid
> > > you will be disappointed: it's in the wrong location, at the wrong time.
> >
> > Hmmm...
> > I don't understand how I can be looking in the wrong location
> > at the wrong time.
> 
> Wrong location and time :
>    trying to speed the parser (location of the optimisation),
>    for an very rarely called function (how many time).
> 
> >
> > I was only looking at a math-part of some POV-Ray code that I
> > found interesting and told others about something that seemed
> > to be a simplification to me.
> >
> > Would you people prefer that I shut up about my findings, just
> > because POV developers are busy with v3.5 coding ?
> 
> I cannot speak for the TAG or the Pov-Team,
> but if you expect your finding to be incorporated in 3.5,
> I think you will be disappointed.
> Most people want now a stable and final 3.5, with sources,
> then the everybody-patching process could restart
> and the super/mega/hyper/pov family shows up again.
> Then you could make your own version of povray and show us the speed up.
> (which may be real for photons, I do not know).

I thought that you meant that the time I posted my
suggestion (late november 2001) was a bad time
because the POV-team had more important things to
do now.

And: I did not expect anything.

- I just made a little suggestion.


Jérôme Grimbert wrote:
>...
> Moreover, I do not have the code of 3.5, do you ?

No, unfortunately not   =(


Jérôme Grimbert wrote:
>...
> Tor Olav Kristensen wrote:
> >...
> > My opinion is that knowledge about any potential speed
> > improvements and simplifications to POV-Ray might be valuable
> > in the future (be it mathematical, logical or algorithmic).
> >
> 
> I think there is an entry for you in the FAQ...

I had a look, but I'm not sure which you mean.
Please show me.


Jérôme Grimbert wrote:
>...
> Tor Olav Kristensen wrote:
> >...
> > I think that if one posts such suggestions here, there is a
> > slight chance that will be read and hopefully remembered when
> > the time to rewrite POV-Ray comes.
> 
> If you really want to search for optimisation, in 3.1, I have one
> to keep you busy: In the pigment evaluation, due to a limited number
> of arguments, one heavy something is done twice (once at top level,
> and another time in a called function).
> Find that, and then solves it cleanly.

Since I'm new to POV's source code I think that
I'll stick to what interests me most within it;
the linear algebra.


Jérôme Grimbert wrote:
>...
> Tor Olav Kristensen wrote:
> >...
> > I doubt that all smart C-compilers today can analyse algebraic
> > expressions and then rearrange them in order to collect items
> > (that are common between several C-expressions) and place them
> > outside parenthesis in all the relevant C-expressions.
> 
> They might do it with a two pass optimiser: first pass count the use of
>  sub-expression. second pass assign a register for the most useful
>  sub-result, according to the available register in the window.
> 
> But they do not have to.
> All they usually need is to keep a symbolic map of the register contents,
> so that if (1-cosx) is still in a register, they used it directly.

Then please show me step by step how they will make
use of a pre-calculated value for (1 - cosx) while
parsing these expressions:

V1[X] * V1[X] + cosx * (1.0 - V1[X] * V1[X])

V1[Y] * V1[Y] + cosx * (1.0 - V1[Y] * V1[Y])

V1[Z] * V1[Z] + cosx * (1.0 - V1[Z] * V1[Z])



Tor Olav

[Tor Olav Kristensen] Re: matrices.c [8903 days 2 hours and 28 minutes ago]

Wed, 5 Dec 2001 00:09:05 GMT

Jérôme Grimbert wrote:
>...
> The original lines where easier for math people, because they were
> simply the traditionnal matrix.
> Your lines are more difficult to recognize as a rotation (at least for me).
>...

Ok, then I'll try to explain how to see that my lines
represent such a rotation...

Please see my post to povray.advanced-users 30. Nov;
"Rotation around an arbitrary axis":
news://news.povray.org/3C06D0B8.9DE747A0%40hotmail.com
http://news.povray.org/povray.advanced-users/20370/

- and my explanation below.


Tor Olav


Here's is a matrix expression that shows how one can
build a general rotation matrix R, that will represent
a rotation around a given unit vector v = <a, b, c>
in a left handed coordinate system:

R = -Sin*S + (1 - Cos)*S*S + I

(Sin means sin(Angle) and Cos means cos(Angle).)

S is this skew symmetric matrix:

     0 -c  b
S =  c  0 -a
    -b  a  0

(I have seen this written like this S = skew(v))

And I is an identity matrix:

     1  0  0
I =  0  1  0
     0  0  1

Rewriting the first expression:

                  0  -c   b    -Sin*0  Sin*c -Sin*b
-Sin*S = -Sin  *  c   0  -a  = -Sin*c -Sin*0  Sin*a
                 -b   a   0     Sin*b -Sin*a -Sin*0

     0    c*Sin -b*Sin
= -c*Sin    0    a*Sin
   b*Sin -a*Sin    0  


Then we'll work with the rest of the expression.

Multiplying matrix S by itself:

       0 -c  b     0 -c  b     0*0-c*c-b*b -0*c+c*0+b*a -0*b+c*a-b*0
S*S =  c  0 -a  *  c  0 -a  = -c*0-0*c+a*b -c*c+0*0-a*a  c*b+0*a+a*0
      -b  a  0    -b  a  0     b*0+a*c+0*b  b*c-a*0-0*a -b*b-a*a+0*0

  -(b^2+c^2)     b*a         c*a   
=     a*b    -(a^2+c^2)      c*b   
      a*c        b*c     -(a^2+b^2)


Since v is a vector with unit length:

sqrt(a^2 + b^2 + c^2) = 1

or simply:

a^2 + b^2 + c^2 = 1

Here's three ways to rearrange that:

-(b^2 + c^2) = a^2 - 1
-(a^2 + c^2) = b^2 - 1
-(a^2 + b^2) = c^2 - 1


Substitution:

       a*a-1   b*a    c*a      a*a  b*a  c*a     1  0  0
S*S =  a*b     b*b-1  c*b   =  a*b  b*b  c*b  -  0  1  0
       a*c     b*c    c*c-1    a*c  b*c  c*c     0  0  1


Scaling with (1 - Cos):
                
(1-Cos)*S*S

            a*a  b*a  c*a               1  0  0
= (1-Cos) * a*b  b*b  c*b  -  (1-Cos) * 0  1  0
            a*c  b*c  c*c               0  0  1

            a*a  b*a  c*a     Cos  0   0     1  0  0
= (1-Cos) * a*b  b*b  c*b  +   0  Cos  0  -  0  1  0
            a*c  b*c  c*c      0   0  Cos    0  0  1


Adding an identity matrix:

(1-Cos)*S*S + I

            a*a  b*a  c*a     Cos  0   0 
= (1-Cos) * a*b  b*b  c*b  +   0  Cos  0 
            a*c  b*c  c*c      0   0  Cos 


Now we can tell that:

R = -Sin*S + (1-Cos)*S*S + I

     0    c*Sin -b*Sin               a*a  b*a  c*a     Cos  0   0 
= -c*Sin    0    a*Sin  +  (1-Cos) * a*b  b*b  c*b  +   0  Cos  0 
   b*Sin -a*Sin    0                 a*c  b*c  c*c      0   0  Cos 

    Cos   c*Sin -b*Sin               a*a  b*a  c*a
= -c*Sin   Cos   a*Sin  +  (1-Cos) * a*b  b*b  c*b
   b*Sin -a*Sin   Cos                a*c  b*c  c*c

    Cos   c*Sin -b*Sin     a*a*(1-Cos)  b*a*(1-Cos)  c*a*(1-Cos)
= -c*Sin   Cos   a*Sin  +  a*b*(1-Cos)  b*b*(1-Cos)  c*b*(1-Cos)
   b*Sin -a*Sin   Cos      a*c*(1-Cos)  b*c*(1-Cos)  c*c*(1-Cos)


Finally we'll do another matrix addition to get one single matrix:

     a*a*(1-Cos)+Cos    b*a*(1-Cos)+c*Sin  c*a*(1-Cos)-b*Sin
R =  a*b*(1-Cos)-c*Sin  b*b*(1-Cos)+Cos    c*b*(1-Cos)+a*Sin
     a*c*(1-Cos)+b*Sin  b*c*(1-Cos)-a*Sin  c*c*(1-Cos)+Cos  

And from this we see that:

R[0][0] = a*a*(1 - Cos) + Cos
R[0][1] = b*a*(1 - Cos) + c*Sin
R[0][2] = c*a*(1 - Cos) - b*Sin

R[1][0] = a*b*(1 - Cos) - c*Sin
R[1][1] = b*b*(1 - Cos) + Cos
R[1][2] = c*b*(1  -Cos) + a*Sin

R[2][0] = a*c*(1 - Cos) + b*Sin
R[2][1] = b*c*(1 - Cos) - a*Sin
R[2][2] = c*c*(1 - Cos) + Cos


Now if:

v = V1 (a = V1[X], b = V1[Y], c = V1[Z])
cosx = Cos
sinx = Sin
omc = 1-Cos

Then it's easy to see that:

transform->matrix = R

> >   transform->matrix[0][0] = V1[X] * V1[X] * omc + cosx;
> >   transform->matrix[0][1] = V1[X] * V1[Y] * omc + V1[Z] * sinx;
> >   transform->matrix[0][2] = V1[X] * V1[Z] * omc - V1[Y] * sinx;
> >
> >   transform->matrix[1][0] = V1[X] * V1[Y] * omc - V1[Z] * sinx;
> >   transform->matrix[1][1] = V1[Y] * V1[Y] * omc + cosx;
> >   transform->matrix[1][2] = V1[Y] * V1[Z] * omc + V1[X] * sinx;
> >
> >   transform->matrix[2][0] = V1[X] * V1[Z] * omc + V1[Y] * sinx;
> >   transform->matrix[2][1] = V1[Y] * V1[Z] * omc - V1[X] * sinx;
> >   transform->matrix[2][2] = V1[Z] * V1[Z] * omc + cosx;

[Jérôme Grimbert] Re: matrices.c [8908 days 16 hours and 54 minutes ago]

Thu, 29 Nov 2001 09:43:32 GMT

Mark Wagner wrote:
> 
> Does this matter?  His code will run faster.

Unproven assertition (yet).

> 
> >They might do it with a two pass optimiser: first pass count the use of
> > sub-expression. second pass assign a register for the most useful
> > sub-result, according to the available register in the window.
> >
> >But they do not have to.
> >All they usually need is to keep a symbolic map of the register contents,
> >so that if (1-cosx) is still in a register, they used it directly.
> 
> Did you look at what Tor did? 

[This discussion is turning ad hominem, so I will not enter more into it]

> No compiler in the world will make that
> particular optimization, because it involves symbolic algebra. 

May be I'm too optimistic about optimisers, or you're too pessimistic.

Only solution to settle this patch down:
 1. Get the pov source.
 2. Make your own compilation to obtain povray-1.
 3. Patch as suggested
 4. Make another clean compilation to obtain povray-2.
 5. Testing time (either, or both, as you like):
   5.1 : make povray-1 and povray-2 render all the pov-scenes that comes 
         with the source.
         Keep the time log. 
         Any difference of less that the precision is irrelevant.
         (precision is usually 1 second).
   5.2 : create a specific scenes on purpose of triggering the patch. 
         Render with both.
         Compare the time needed.
 6. Report the result worldwide.

For both compilation, exactly the same compiler and the same options must be
used.

As the current code of pov is assumed to be innocent, 
the charge of the proof fall to the evolution-requestor.

[Mark Wagner] Re: matrices.c [8908 days 21 hours and 35 minutes ago]

Thu, 29 Nov 2001 05:02:25 GMT

Jérôme Grimbert wrote in message <3C0### [at] atosorigincom>...
>> BUT:
>> Did you look thoroughly at this part of the code I suggested ?
>>
>Not really, I confess.

[code removed]

>> If so, I hope that you noticed that the (1.0 - cosx) expression
>> here appears in all of the transform lines, while it did not
>> appear in 3 of those lines originally.
>
>The original lines where easier for math people, because they were
>simply the traditionnal matrix.
>Your lines are more difficult to recognize as a rotation (at least for me).

Does this matter?  His code will run faster.

>They might do it with a two pass optimiser: first pass count the use of
> sub-expression. second pass assign a register for the most useful
> sub-result, according to the available register in the window.
>
>But they do not have to.
>All they usually need is to keep a symbolic map of the register contents,
>so that if (1-cosx) is still in a register, they used it directly.


Did you look at what Tor did?  No compiler in the world will make that
particular optimization, because it involves symbolic algebra.  In the
original code, the expression (1.0 - cosx) appears *six* times.  An
optimizing compiler will notice this and evaluate it only once, storing the
result in either a CPU register or memory, whichever is appropriate.  What
Tor did was notice that with a certain algebraic manipulation, the
expressions such as V1[X] * V1[X] + cosx * (1.0 - V1[X] * V1[X])could be
converted into expressions like V1[X] * V1[X] * (1.0 + cosx) + cosx,
allowing the *nine* occurrences of (1.0 - cosx) to be recognized as a common
subexpression which need only be evaluated once.

--
Mark

[Peter Popov] Re: POVRAY-Rendering in networks? [8909 days 11 hours and 25 minutes ago]

Wed, 28 Nov 2001 15:12:10 GMT

On Wed, 28 Nov 2001 23:18:11 +1000, "Davin"
<dav### [at] itcmconsultcomau> wrote:

>Just wondering,
>what are the Radiosity problems with splitting a single frame across
>mutliple machines?

In brief, the radiosity samples are kept in a structure known as an
octree. The radiosity octree is created during pre-rendering and
rendering. Therefore the nodes have to somehow share the information
they add to the octree so that they use identical copies. Francois
Dispot has solved the problem, to a large extent, in PVM-MegaPOV and
can probably enlighten you more on the subject.

Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[Davin] Re: POVRAY-Rendering in networks? [8909 days 13 hours and 19 minutes ago]

Wed, 28 Nov 2001 13:18:13 GMT

Just wondering,
what are the Radiosity problems with splitting a single frame across
mutliple machines?

"Apache" <apa### [at] yahoocom> wrote in message
news:3bfcf291$1@news.povray.org...
> > Note that only individual frames are rendered. It will not split up
> > single frames across multiple computers.
>
> That perfect: no radiosity problems at this point!
>
>

[Jérôme Grimbert] Re: matrices.c [8909 days 17 hours and 37 minutes ago]

Wed, 28 Nov 2001 09:00:35 GMT

Tor Olav Kristensen wrote:
> 
> Jérôme Grimbert wrote:
> >
> > Tor Olav Kristensen wrote:
> > >
> > > (from megasrc07.zip)
> > >
> > > I have just had a little peek into that c-file
> > > and found that it might be possible to do some
> > > simplifications of the code within it.
> > >
> > [SNIP]
> > > This introduces one extra local variable; omc,
> > > but I hope there will be a little speed gain anyway.
> >
> > Do you have any idea WHEN Compute_Axis_Rotation_Transform is called ?
> > And how many time ?
> > My current guess is (because I did not check yet,
> > only performing from memory of the code):
> >  - At parse time only.
> >  - once per invoking directive.
> 
> Yes, I checked were it was called from prior to posting,
> - and found that it was only called from Express.c in
> the official version (v3.1g).
> 
> But I found that in MegaPOV it was also called from photons.c;
> i.e. from ShootPhotonsAtObject() in relation with the jitter
> option for area lights.
> 

I did not know about MegaPov sources.

> > If you were trying to get some significant speed improvement, I'm afraid
> > you will be disappointed: it's in the wrong location, at the wrong time.
> 
> Hmmm...
> I don't understand how I can be looking in the wrong location
> at the wrong time.

Wrong location and time : 
   trying to speed the parser (location of the optimisation), 
   for an very rarely called function (how many time).

> 
> I was only looking at a math-part of some POV-Ray code that I
> found interesting and told others about something that seemed
> to be a simplification to me.
> 
> Would you people prefer that I shut up about my findings, just
> because POV developers are busy with v3.5 coding ?

I cannot speak for the TAG or the Pov-Team, 
but if you expect your finding to be incorporated in 3.5, 
I think you will be disappointed.
Most people want now a stable and final 3.5, with sources,
then the everybody-patching process could restart 
and the super/mega/hyper/pov family shows up again.
Then you could make your own version of povray and show us the speed up.
(which may be real for photons, I do not know).

Moreover, I do not have the code of 3.5, do you ?

> 
> My opinion is that knowledge about any potential speed
> improvements and simplifications to POV-Ray might be valuable
> in the future (be it mathematical, logical or algorithmic).
> 

I think there is an entry for you in the FAQ...

> I think that if one posts such suggestions here, there is a
> slight chance that will be read and hopefully remembered when
> the time to rewrite POV-Ray comes.

If you really want to search for optimisation, in 3.1, I have one
to keep you busy: In the pigment evaluation, due to a limited number 
of arguments, one heavy something is done twice (once at top level, 
and another time in a called function). 
Find that, and then solves it cleanly.

> 
> (Yes, I see now that I should probably should have posted to
> povray.programming instead.)
> 
> > P.S.: If I am wrong, do not hesitate: Open fire... I will apologise later.
> >
> 
> The fact that v3.1g does not use Compute_Axis_Rotation_Transform()
> to do time consuming stuff, while MegaPOV seems to do, suggests
> that it might be wise to code such small "general" routines with
> care.

If you really want to be smarter than the compiler, you might as well
replace the 'transform->matrix' indirection to something more direct.
It will be useless with most modern CPU, it will render the code more
obfuscated.
You may also want to assign V1[...] to some variable, because they are
used a lot and some believe than index of array take time to resolve.
It would be also useless.

I agree nevertheless with you, that care should be taken to correctly
write the code to avoid unnecessary operations, but the most important
thing should be to COMMENT the tricky code at high/medium and low level.
(High level being the pure math thing, : 
        compute a rotation matrix around axis V at the origin...
 Medium level : 
     formula of the matrix is ....
 Low level:
     (1 - cosx) is used everywhere, do it only once.
)

> 
> > P.S.2: Smart compiler may already have factored
> > the (1 - cosx) result in a register, so forcing to use a named variable
> > might even be counter productive (because it must be written to the memory
> > location, for nothing).
> 
> Yes, a colleague of mine told me that too this morning,
> 
> BUT:
> Did you look thoroughly at this part of the code I suggested ?
> 
Not really, I confess.

>   cosx = cos(angle);
>   sinx = sin(angle);
>   omc = 1.0 - cosx;
> 
>   transform->matrix[0][0] = V1[X] * V1[X] * omc + cosx;
>   transform->matrix[0][1] = V1[X] * V1[Y] * omc + V1[Z] * sinx;
>   transform->matrix[0][2] = V1[X] * V1[Z] * omc - V1[Y] * sinx;
> 
>   transform->matrix[1][0] = V1[X] * V1[Y] * omc - V1[Z] * sinx;
>   transform->matrix[1][1] = V1[Y] * V1[Y] * omc + cosx;
>   transform->matrix[1][2] = V1[Y] * V1[Z] * omc + V1[X] * sinx;
> 
>   transform->matrix[2][0] = V1[X] * V1[Z] * omc + V1[Y] * sinx;
>   transform->matrix[2][1] = V1[Y] * V1[Z] * omc - V1[X] * sinx;
>   transform->matrix[2][2] = V1[Z] * V1[Z] * omc + cosx;
> 
> If so, I hope that you noticed that the (1.0 - cosx) expression
> here appears in all of the transform lines, while it did not
> appear in 3 of those lines originally.

The original lines where easier for math people, because they were
simply the traditionnal matrix. 
Your lines are more difficult to recognize as a rotation (at least for me).

> 
> I doubt that all smart C-compilers today can analyse algebraic
> expressions and then rearrange them in order to collect items
> (that are common between several C-expressions) and place them
> outside parenthesis in all the relevant C-expressions.

They might do it with a two pass optimiser: first pass count the use of
 sub-expression. second pass assign a register for the most useful
 sub-result, according to the available register in the window.

But they do not have to.
All they usually need is to keep a symbolic map of the register contents,
so that if (1-cosx) is still in a register, they used it directly.

It's not really useful on Intel family, due to the lack of generic
registers in x8086 mode, but on most RISC cpu it make the code really flies.
(It's also great on the old M680xx family, which is a CISC cpu).

If the optimiser is allowed to perform out-of-order execution, it can even 
be more surprising. (you may want to try to store V1[X]*omc, V1[Y]*omc and
 V1[Z]*omc , because these three sub-expression are used three time in your
code.

Anyway, rearranging expressions is also the very first step of 
common optimisation, but usually they try only to factor constant expressions.

If povray was not portable across various CPU, you could even go further
with the exact timeframe of CPU operation (with also possible out-of-order
optim)
and hand-code in assembly the PERFECT sequence of operation.

Alas, even in the pentium family, the Perfect sequence of P1 is not the
perfect one for P2/P3 and not even for P4. (And you did not look at AMD...)

[Tor Olav Kristensen] Re: matrices.c [8910 days 1 hour and 48 minutes ago]

Wed, 28 Nov 2001 00:49:29 GMT

Jérôme Grimbert wrote:
> 
> Tor Olav Kristensen wrote:
> >
> > (from megasrc07.zip)
> >
> > I have just had a little peek into that c-file
> > and found that it might be possible to do some
> > simplifications of the code within it.
> >
> [SNIP]
> > This introduces one extra local variable; omc,
> > but I hope there will be a little speed gain anyway.
> 
> Do you have any idea WHEN Compute_Axis_Rotation_Transform is called ?
> And how many time ?
> My current guess is (because I did not check yet,
> only performing from memory of the code):
>  - At parse time only.
>  - once per invoking directive.

Yes, I checked were it was called from prior to posting,
- and found that it was only called from Express.c in
the official version (v3.1g).

But I found that in MegaPOV it was also called from photons.c;
i.e. from ShootPhotonsAtObject() in relation with the jitter
option for area lights. 

So therefore I assumed that it might get called a lot if many
photons were shot from a jittering area light.

(Compute_Axis_Rotation_Transform() is also called from render.c,
in relation with SPHERICAL_CAMERA, but I haven't looked at that
code yet.)

> If you were trying to get some significant speed improvement, I'm afraid
> you will be disappointed: it's in the wrong location, at the wrong time.

Hmmm...
I don't understand how I can be looking in the wrong location
at the wrong time.

I was only looking at a math-part of some POV-Ray code that I
found interesting and told others about something that seemed
to be a simplification to me.

Would you people prefer that I shut up about my findings, just
because POV developers are busy with v3.5 coding ?

My opinion is that knowledge about any potential speed
improvements and simplifications to POV-Ray might be valuable
in the future (be it mathematical, logical or algorithmic).

I think that if one posts such suggestions here, there is a
slight chance that will be read and hopefully remembered when
the time to rewrite POV-Ray comes.

(Yes, I see now that I should probably should have posted to
povray.programming instead.)

> P.S.: If I am wrong, do not hesitate: Open fire... I will apologise later.
> 

The fact that v3.1g does not use Compute_Axis_Rotation_Transform()
to do time consuming stuff, while MegaPOV seems to do, suggests
that it might be wise to code such small "general" routines with
care.

> P.S.2: Smart compiler may already have factored
> the (1 - cosx) result in a register, so forcing to use a named variable
> might even be counter productive (because it must be written to the memory
> location, for nothing).

Yes, a colleague of mine told me that too this morning,

BUT:
Did you look thoroughly at this part of the code I suggested ?

  cosx = cos(angle);
  sinx = sin(angle);
  omc = 1.0 - cosx;

  transform->matrix[0][0] = V1[X] * V1[X] * omc + cosx;
  transform->matrix[0][1] = V1[X] * V1[Y] * omc + V1[Z] * sinx;
  transform->matrix[0][2] = V1[X] * V1[Z] * omc - V1[Y] * sinx;

  transform->matrix[1][0] = V1[X] * V1[Y] * omc - V1[Z] * sinx;
  transform->matrix[1][1] = V1[Y] * V1[Y] * omc + cosx;
  transform->matrix[1][2] = V1[Y] * V1[Z] * omc + V1[X] * sinx;

  transform->matrix[2][0] = V1[X] * V1[Z] * omc + V1[Y] * sinx;
  transform->matrix[2][1] = V1[Y] * V1[Z] * omc - V1[X] * sinx;
  transform->matrix[2][2] = V1[Z] * V1[Z] * omc + cosx;

If so, I hope that you noticed that the (1.0 - cosx) expression
here appears in all of the transform lines, while it did not
appear in 3 of those lines originally.

I doubt that all smart C-compilers today can analyse algebraic
expressions and then rearrange them in order to collect items
(that are common between several C-expressions) and place them
outside parenthesis in all the relevant C-expressions.

There are some calculators and computer programs that can do
such manipulation stuff to a whole lot of different types of
symbolic expressions (differentiation, integration, trigonometry
math, matrix math, complex number math etc...)

But does anybody know if such skills have been implemented in
ANY C-compilers yet ?

Tor Olav

[Jérôme Grimbert] Re: matrices.c [8910 days 13 hours and 16 minutes ago]

Tue, 27 Nov 2001 13:21:34 GMT

Tor Olav Kristensen wrote:
> 
> (from megasrc07.zip)
> 
> I have just had a little peek into that c-file
> and found that it might be possible to do some
> simplifications of the code within it.
> 
[SNIP]
> This introduces one extra local variable; omc,
> but I hope there will be a little speed gain anyway.

Do you have any idea WHEN Compute_Axis_Rotation_Transform is called ?
And how many time ?

My current guess is (because I did not check yet, 
only performing from memory of the code):
 - At parse time only.
 - once per invoking directive.

If you were trying to get some significant speed improvement, I'm afraid
you will be disappointed: it's in the wrong location, at the wrong time.

P.S.: If I am wrong, do not hesitate: Open fire... I will apologise later.

P.S.2: Smart compiler may already have factored 
the (1 - cosx) result in a register, so forcing to use a named variable
might even be counter productive (because it must be written to the memory
location, for nothing).

[Tor Olav Kristensen] matrices.c [8913 days 7 hours and 28 minutes ago]

Sat, 24 Nov 2001 19:09:31 GMT

(from megasrc07.zip)

I have just had a little peek into that c-file
and found that it might be possible to do some
simplifications of the code within it.


So here's my suggestion:

Replace this:
(27 multiplications and 18 additions/subtractions)


#ifdef AxisRotFixPatch
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR
AxisVect, DBL angle)
{
  DBL cosx, sinx;
  VECTOR V1;

  VNormalize(V1, AxisVect);
#else
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR V1,
DBL angle)
{
  DBL l, cosx, sinx;

  VLength(l, V1);
  VInverseScaleEq(V1, l);
#endif

  MIdentity(transform->matrix);

  cosx = cos(angle);
  sinx = sin(angle);

  transform->matrix[0][0] = V1[X] * V1[X] + cosx * (1.0 - V1[X] *
V1[X]);
  transform->matrix[0][1] = V1[X] * V1[Y] * (1.0 - cosx) + V1[Z] * sinx;
  transform->matrix[0][2] = V1[X] * V1[Z] * (1.0 - cosx) - V1[Y] * sinx;

  transform->matrix[1][0] = V1[X] * V1[Y] * (1.0 - cosx) - V1[Z] * sinx;
  transform->matrix[1][1] = V1[Y] * V1[Y] + cosx * (1.0 - V1[Y] *
V1[Y]);
  transform->matrix[1][2] = V1[Y] * V1[Z] * (1.0 - cosx) + V1[X] * sinx;

  transform->matrix[2][0] = V1[X] * V1[Z] * (1.0 - cosx) + V1[Y] * sinx;
  transform->matrix[2][1] = V1[Y] * V1[Z] * (1.0 - cosx) - V1[X] * sinx;
  transform->matrix[2][2] = V1[Z] * V1[Z] + cosx * (1.0 - V1[Z] *
V1[Z]);

  MTranspose(transform->inverse, transform->matrix);
}


With this:
(24 multiplications and 10 additions/subtractions)


#ifdef AxisRotFixPatch
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR
AxisVect, DBL angle)
{
  DBL cosx, sinx, omc;
  VECTOR V1;

  VNormalize(V1, AxisVect);
#else
void Compute_Axis_Rotation_Transform (TRANSFORM *transform, VECTOR V1,
DBL angle)
{
  DBL l, cosx, sinx, omc;

  VLength(l, V1);
  VInverseScaleEq(V1, l);
#endif

  MIdentity(transform->matrix);

  cosx = cos(angle);
  sinx = sin(angle);
  omc = 1.0 - cosx;

  transform->matrix[0][0] = V1[X] * V1[X] * omc + cosx;
  transform->matrix[0][1] = V1[X] * V1[Y] * omc + V1[Z] * sinx;
  transform->matrix[0][2] = V1[X] * V1[Z] * omc - V1[Y] * sinx;

  transform->matrix[1][0] = V1[X] * V1[Y] * omc - V1[Z] * sinx;
  transform->matrix[1][1] = V1[Y] * V1[Y] * omc + cosx;
  transform->matrix[1][2] = V1[Y] * V1[Z] * omc + V1[X] * sinx;

  transform->matrix[2][0] = V1[X] * V1[Z] * omc + V1[Y] * sinx;
  transform->matrix[2][1] = V1[Y] * V1[Z] * omc - V1[X] * sinx;
  transform->matrix[2][2] = V1[Z] * V1[Z] * omc + cosx;

  MTranspose(transform->inverse, transform->matrix);
}


This introduces one extra local variable; omc,
but I hope there will be a little speed gain anyway.


Tor Olav

[Apache] Re: POVRAY-Rendering in networks? [8915 days 13 hours and 55 minutes ago]

Thu, 22 Nov 2001 12:41:53 GMT

> Note that only individual frames are rendered. It will not split up
> single frames across multiple computers.

That perfect: no radiosity problems at this point!

[Ken] Re: POVRAY-Rendering in networks? [8915 days 19 hours and 22 minutes ago]

Thu, 22 Nov 2001 07:15:17 GMT

Apache wrote:
> 
> Thanks! I just sent the people of IMP a request for more info.
> 
> I'm wondering about the technical background of IMP. Is it fully automated
> or do I receive parts of the project by mail or something?

As far as I know it is all done through the internet via TCP/IP protocols.
There are "jobs" uploaded to the render queue at the IMP website. When
you fire up IMP-Pov and log on and it will check to see if any jobs are
waiting.

> If it would be
> fully automated I could leave a computer running for weeks without
> intervening and stuff.

Once you have it up and running it is fully automated as long as there
are render tasks left in the queue.  If you have an always on connection,
or an unlimited access dial up connection, you could theoretically render
for months on end.

Note that only individual frames are rendered. It will not split up
single frames across multiple computers.

-- 
Ken Tyler

[Apache] Re: POVRAY-Rendering in networks? [8915 days 20 hours and 6 minutes ago]

Thu, 22 Nov 2001 06:31:36 GMT

Thanks! I just sent the people of IMP a request for more info.

I'm wondering about the technical background of IMP. Is it fully automated
or do I receive parts of the project by mail or something? If it would be
fully automated I could leave a computer running for weeks without
intervening and stuff.

[Daniel Matthews] Re: POVRAY-Rendering in networks? [8915 days 20 hours and 50 minutes ago]

Thu, 22 Nov 2001 05:47:26 GMT

http://www.imp.org

Apache wrote:

> Nowadays lotsa people are sharing data (Napster, KaZaA, Xolox, etcetera
> etcetera). But what about cpu sharing? It would be neat if members of the
> 'povray community' with spare cpu time could form a 'rendering pool' or
> something. In many cases this would really speed up renderings.
> 
> Anyone any ideas or information?

[Mark Wagner] Re: [C++] Question about reinterpret_cast<> [8915 days 21 hours and 2 minutes ago]

Thu, 22 Nov 2001 05:35:22 GMT

Tim Chan wrote in message <3bfbf514$1@news.povray.org>...
>Hello, I'm studying C++ on my own and would appreciate some help.


[program snipped]

>I don't understand this line:
>
>****   print(reinterpret_cast<X*>(xp));  ****
>
>why do you pass 'xp' into the cast but not '&xp'....?

xp is of type pointer to int, and you are converting it to the type pointer
to X.  &xp would be the address of xp, and would be of type pointer to
pointer to int.

>Because earlier you need to pass the address of x into the cast:
>
>****  int* xp = reinterpret_cast<int*>(&x);  ****


Here, x is of type X.  &x is the memory address of x, and is of type pointer
to X.  The reinterpret_cast converts that to type pointer to int.

--
Mark

[Apache] Re: POVRAY-Rendering in networks? [8915 days 22 hours ago]

Thu, 22 Nov 2001 04:37:11 GMT

Nowadays lotsa people are sharing data (Napster, KaZaA, Xolox, etcetera
etcetera). But what about cpu sharing? It would be neat if members of the
'povray community' with spare cpu time could form a 'rendering pool' or
something. In many cases this would really speed up renderings.

Anyone any ideas or information?

[Tim Chan] [C++] Question about reinterpret_cast<> [8916 days 7 hours and 57 minutes ago]

Wed, 21 Nov 2001 18:40:20 GMT

Hello, I'm studying C++ on my own and would appreciate some help.

In the following Program:-

#include <iostream>
using namespace std;
const int sz = 100;

struct X { int a[sz]; };

void print(X* x) {
  for(int i = 0; i < sz; i++)
    cout << x->a[i] << ' ';
  cout << endl << "--------------------" << endl;
}

int main() {
  X x;
  print(&x);

  int* xp = reinterpret_cast<int*>(&x);

  for(int* i = xp; i < xp + sz; i++)
    *i = 0;

  print(reinterpret_cast<X*>(xp));

} ///:~


I don't understand this line:

****   print(reinterpret_cast<X*>(xp));  ****

why do you pass 'xp' into the cast but not '&xp'....?
Because earlier you need to pass the address of x into the cast:

****  int* xp = reinterpret_cast<int*>(&x);  ****

Please help me cos i've been thinking about this for so unnecessarily long.

Cheers, Tim.

[s1631001] Re: Documentation for splines? [8916 days 11 hours and 55 minutes ago]

Wed, 21 Nov 2001 14:42:31 GMT

Excellent, that would come in useful  <--  (hates trying to hand-code splines)

I've got a bit of working knowledge about splines if you want it?  <--
(trying to create a cool spline #macro for POV)

//@---signature---
//  Grey Knight's site of the week: http://heday.freeservers.com/

Sebastian Holtermann wrote:

> Hi there
>
> Does anyone know an online documentation for creating splines curves and
> that stuff especially the math behind it.
>
> The page mentioned in the pov link list has some examples but it seemed to
> that one had to have a basic knowledge of what splines are.
>
> I plan to code (another?) lathe/sor (spline?) editor for povray for linux
> (gtk or so).
>
> Thank you.
>
> --
> Sebastian H.

[Thorsten Froehlich] Finding all #include files in a POV-Ray scene file [8949 days 7 hours and 15 minutes ago]

Fri, 19 Oct 2001 19:21:57 GMT

The attached code is useful for finding #include files in a POV-Ray scene 
file.  With proper use it can work recursively.  There are two restrictions
which affect only a very small number of scene files:
1. The parser does not allow the "#" and the "include" to be separated by
spaces or tabs like the POV-Ray parser currently does.
2. Include file names assembled by string functions are not supported.

    Thorsten

NOTE: While this example code is provided under a very liberal license,
older or newer versions of this source code that may be found in the POV-Ray
source code are still governed by povlegal.doc!

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

[John Albarelli] Image MapTutorial? [8956 days 7 hours and 51 minutes ago]

Fri, 12 Oct 2001 18:46:15 GMT

Anybody know of a good online image map tutorial?  Or feel like typing one
up?  I know the basics, how to map an image to a plane, sphere, cylinder,
etc.  I am having some trouble with transmit and filter, though, in the
process of creating a partly transparent image map.  Can anyone help?
Thanks.

John

[Peter Popov] (OT) Help with my little ratyracer (C++) - proje... [9022 days 13 hours and 37 minutes ago]

Tue, 7 Aug 2001 13:00:46 GMT

See post in povray.programming


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

[Geoff Wedig] Re: new pattern simulating a wall of interlockin... [9044 days 13 hours and 42 minutes ago]

Mon, 16 Jul 2001 12:55:36 GMT

Jim Snow <jsn### [at] csgeorgefoxedu> wrote:

> Geoff Wedig <wed### [at] darwinepbicwruedu> wrote in article
> <3b4ef7c6@news.povray.org>...
>> Very interesting.  Have you seen my isosurface stone walling code?  It
> looks
>> to be doing similar sorts of things, though I think mine is a little bit
>> more intelligent (in that it does things as a stone mason might do, like
>> making sure stones are wider than tall, etc)  It's slow, since it's in
> pov
>> native code, and then uses iso surfaces, but on the other hand, allows
> for
>> lots of nifty stuff like roughing up the surface and morphing it into
> cones
>> and cylinders and such by changing the iso function.
>> 
>> I haven't looked at your code since I'm pretty much a novice to the POV
>> source.
>> 
>> Geoff
>>

> Where can I find this code?

It's never been publically released, due to lack of docs.  But it's pretty
well commented.  It started out as an isosurface update to the mur.inc, but
then I decided that the algorithm used in mur.inc was inadequate for my
needs.  If you want a copy, let me know and I'll send you the files.

> By the way, you can make the stones tend to be more wide than high and vice
> versa with my algorithm by tweaking some numbers in the c code.  I was
> thinking of using my function in an isosurface, but I haven't really
> figured out how isosurfaces work.

They're not as hard as they seem to be at first glance.  I've become quite
enamored with them.  But there is a learning curve, mostly due to a lot of
parameters that, without a good idea of how they work, don't make much
sense.

Geoff

[Jim Snow] Re: new pattern simulating a wall of interlockin... [9047 days 1 hour and 42 minutes ago]

Sat, 14 Jul 2001 00:55:15 GMT

Geoff Wedig <wed### [at] darwinepbicwruedu> wrote in article
<3b4ef7c6@news.povray.org>...
> Very interesting.  Have you seen my isosurface stone walling code?  It
looks
> to be doing similar sorts of things, though I think mine is a little bit
> more intelligent (in that it does things as a stone mason might do, like
> making sure stones are wider than tall, etc)  It's slow, since it's in
pov
> native code, and then uses iso surfaces, but on the other hand, allows
for
> lots of nifty stuff like roughing up the surface and morphing it into
cones
> and cylinders and such by changing the iso function.
> 
> I haven't looked at your code since I'm pretty much a novice to the POV
> source.
> 
> Geoff
>

Where can I find this code?

By the way, you can make the stones tend to be more wide than high and vice
versa with my algorithm by tweaking some numbers in the c code.  I was
thinking of using my function in an isosurface, but I haven't really
figured out how isosurfaces work.

-jim

[Bob H ] Re: new pattern simulating a wall of interlockin... [9047 days 3 hours and 15 minutes ago]

Fri, 13 Jul 2001 23:22:13 GMT

"Jim Snow" <jsn### [at] csgeorgefoxedu> wrote in message
news:01c10b10$0b7fed40$93811c26@jmsWin95...
> Bob H. <omn### [at] msncom> wrote in article <3b4e5daa@news.povray.org>...
> > Isn't the cells pattern much like this?  I'm not exactly sure myself.
> >
>
> No, the cells pattern picks a random value between 0 and 1 for each unit
> cube, such that every point in each cube has the same value.  My pattern
> creates blocks of random dimensions that interlock.

Sorry, yes, I see now.  I thought the cells pattern could be changed somehow
but it looks like turbulence is about it, and that only deforms the
boundaries in nonlinear ways.
Thanks for replying to clear that up.

Bob H.

[Ron Parker] Re: new pattern simulating a wall of interlockin... [9047 days 6 hours and 38 minutes ago]

Fri, 13 Jul 2001 19:59:37 GMT

On 13 Jul 2001 15:33:26 -0400, Jim Snow wrote:
>
>I thought about alternating verticals and horizontals, but decided it would
>make the texture look a little too predictable.

I drew a dozen or so squares by hand and it didn't look as predictable as
one might expect, believe it or not.

>  However, the algorithm
>could be vastly simplified - instead of testing distance from the
>originating points to determine which mortar line wins when they intersect,
>I could make it so that a mortar line always wins within its own square and
>loses outside its own square.  The search grid would only have to be 3x3 to
>garuntee that no line escapes the grid.

And you wouldn't have to test the corner squares, either.


-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

[Jim Snow] Re: new pattern simulating a wall of interlockin... [9047 days 7 hours and 4 minutes ago]

Fri, 13 Jul 2001 19:33:26 GMT

Ron Parker <ron### [at] povrayorg> wrote in article
<slr### [at] fwicom>...
> So, here is my thought:  Pick your seed points the same way crackle picks
> its centroids (except in 2D, obviously.)  For each square, determine the 
> sum of its coordinates.  If that sum is even, make the seed point draw a 
> horizontal line.  If it's odd, make the seed point draw a vertical line. 

> Now, when a mortar line leaves its enclosing square it's likely to meet a

> line going the other way within the next square (unless the line going
the 
> other way was stopped by the line that came from the opposite face of the

> square.)   It's still possible to have infinite lines, but they're very 
> very unlikely.  It's unlikely that a line will make it more than 3
squares
> away, I'd think, meaning you might need to search as many as 50 points
> for each test.  But you should be able to cache the results of those
tests
> to some extent to take advantage of some of the spatial coherence in the
> raytracing algorithm, as the crackle pattern does.
> 
> -- 
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z
a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F
T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission
3-T}}}#end 
> Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
> 

I thought about alternating verticals and horizontals, but decided it would
make the texture look a little too predictable.  However, the algorithm
could be vastly simplified - instead of testing distance from the
originating points to determine which mortar line wins when they intersect,
I could make it so that a mortar line always wins within its own square and
loses outside its own square.  The search grid would only have to be 3x3 to
garuntee that no line escapes the grid.

Maybe I should try to make a 3d version with the simpler algorithm.

-jim

[Vahur Krouverk] Re: new pattern simulating a wall of interlockin... [9047 days 10 hours and 41 minutes ago]

Fri, 13 Jul 2001 15:56:08 GMT

Jim Snow wrote:
> extra note:  I tried out Megapov 0.7 today - My patch didn't work quite
> right without adding &0xFFF to the arguments to Hash2d(int, int).  Strange.

Macro HashXd was changed in last version of MegaPOV, see file texture.h,
there is conditional directive:
#ifdef NoiseTranslateFixPatch
In megapov news ( http://nathan.kopp.com/patched.htm ) probably this
line refers to it:
7. Fixed a bug, reported by Nicolas Calimet, in the TransformPatch
(9.2.9) 
Unfortunately I don't remember, what was the proble with this
transformation.

In order to fix this 'nicely' you have to use conditional compilation:
#ifdef NoiseTranslateFixPatch
// use this:
x = Hash2d(a&0xfff, b&0xfff);
#else
x = Hash2d(a, b);
#end
#endif

I had the same problem when merged my code with MegaPOV.

[Ron Parker] Re: new pattern simulating a wall of interlockin... [9047 days 11 hours and 24 minutes ago]

Fri, 13 Jul 2001 15:12:57 GMT

On 13 Jul 2001 04:11:32 -0400, Jim Snow wrote:
>I think that a mortar line can continue infinitely if the points are
>arranged in an "unlucky" fashion.

I'm not convinced that that is true, but proving it either way could be
an interesting project all by itself.

>1.	Pick "random" points within each box such that it is impossible to
>project a vertical or horizontal line through the box without it
>intersecting a mortar line.

This seems like the best solution.  I have some not-very-well-formed thoughts
on this, which I'll elucidate below.

>I'll think about using a noise function for the "random" data - my array of
>random vectors isn't very elegant, even if it is fast.

You might find how the crackle function works interesting.  As you probably
know, the crackle pattern is a 3d voronoi diagram.  Each "stone" has an
apparently randomly positioned centroid, and every point that is closer to
that centroid than to any other is part of that stone.  What isn't so 
obvious on casual examination is that the centroids are not really as 
random as they appear.  All of space is divided into 1x1x1 cubes, and each
cube contains exactly one centroid.  The location of each centroid is 
determined by the values of the Noise3D function at some fixed point within
its enclosing cube, allowing it to be reproducibly calculated as needed.

So, here is my thought:  Pick your seed points the same way crackle picks
its centroids (except in 2D, obviously.)  For each square, determine the 
sum of its coordinates.  If that sum is even, make the seed point draw a 
horizontal line.  If it's odd, make the seed point draw a vertical line.  
Now, when a mortar line leaves its enclosing square it's likely to meet a 
line going the other way within the next square (unless the line going the 
other way was stopped by the line that came from the opposite face of the 
square.)   It's still possible to have infinite lines, but they're very 
very unlikely.  It's unlikely that a line will make it more than 3 squares
away, I'd think, meaning you might need to search as many as 50 points
for each test.  But you should be able to cache the results of those tests
to some extent to take advantage of some of the spatial coherence in the
raytracing algorithm, as the crackle pattern does.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

[Geoff Wedig] Re: new pattern simulating a wall of interlockin... [9047 days 13 hours and 8 minutes ago]

Fri, 13 Jul 2001 13:29:43 GMT

Jim Snow <jsn### [at] csgeorgefoxedu> wrote:

> I wrote a pattern simulating the appearance of a stone wall made of
> rectangular blocks of random size that interlock perfectly.  For an
> example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
> figured out how to integrate it into Pov-RAY so that I can call the pattern
> by name and pass in parameters, so the only way to play with it right now
> is to copy and paste my code into patterns.c and rename my "ashlar"
> function to match the name of another pattern, and comment out that
> pattern.

Very interesting.  Have you seen my isosurface stone walling code?  It looks
to be doing similar sorts of things, though I think mine is a little bit
more intelligent (in that it does things as a stone mason might do, like
making sure stones are wider than tall, etc)  It's slow, since it's in pov
native code, and then uses iso surfaces, but on the other hand, allows for
lots of nifty stuff like roughing up the surface and morphing it into cones
and cylinders and such by changing the iso function.

I haven't looked at your code since I'm pretty much a novice to the POV
source.

Geoff

[Ron Parker] Re: new pattern simulating a wall of interlockin... [9047 days 13 hours and 46 minutes ago]

Fri, 13 Jul 2001 12:51:25 GMT

On 13 Jul 2001 03:31:10 -0400, Jim Snow wrote:
>
>
>Ryan Constantine <rco### [at] yahoocom> wrote in article
><3B4E660E.5D7C1577@yahoo.com>...
>> cool except for one thing.  from your picture, it looks like it is a 2d
>> pattern, not a 3d one.  bummer.
>
>I think the algorithm can be generalized to 3d (but it might be beyond my
>ability to do so), however there would be a problem with the mortar joints
>parallel to the surface of the object occasionally being at the surface of
>the object, resulting in an oddly textured block.  It might not be that big
>of deal, but it would probably be annoying to anyone who just wants their
>stone wall to look good from one side.

Quite true.  That happens with bricks and with crackle occasionally as 
well.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

[Jim Snow] Re: new pattern simulating a wall of interlockin... [9047 days 18 hours and 17 minutes ago]

Fri, 13 Jul 2001 08:20:36 GMT

Bob H. <omn### [at] msncom> wrote in article <3b4e5daa@news.povray.org>...
> Isn't the cells pattern much like this?  I'm not exactly sure myself.
> 
> Bob H.
> 

No, the cells pattern picks a random value between 0 and 1 for each unit
cube, such that every point in each cube has the same value.  My pattern
creates blocks of random dimensions that interlock.

-jim

[Jim Snow] Re: new pattern simulating a wall of interlockin... [9047 days 18 hours and 26 minutes ago]

Fri, 13 Jul 2001 08:11:32 GMT

Ron Parker <ron### [at] povrayorg> wrote in article
<slr### [at] fwicom>...
> On 12 Jul 2001 21:35:58 -0400, Jim Snow wrote:
> >If someone wants to integrate it correctly into Pov-RAY, Megapov, or
> >whatever, be my guest.  You can get my code at
> >"http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?
> 
> It's very interesting.  Have you done any calculations to determine what
> the maximum search will have to be before you're guaranteed not to be on
> a mortar line?  Have you considered using the Noise function instead of
> a random array to determine the positions of the seed points?  That would
> allow your "array" to be essentially infinite, if you could make it fit
> into your algorithm, and it would constrain the positions of the seed 
> points to an extent that you might be able to better predict what the 
> maximum required search is.  
> 
> With those two changes, I think it would be a very useful pattern to 
> have.  Also, I think you could get away with having just a single ratio
> to determine the number of points horizontally vs. the number vertically,
> since you can then scale the bricks to fit your space.
> 
> -- 
> #macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z
a-z)R(a
> -z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F
T)merge{
> P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission
T}}finish{
> reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}
> 

I think that a mortar line can continue infinitely if the points are
arranged in an "unlucky" fashion.
Therefore, it doesn't matter how big the search grid is, you could still
get lines that abruptly stop
without running into anything.  However, I have modified the way "random"
points are chosen in
such a way to make it unlikely that a line makes it much more than one unit
away.  I haven't tested
it enough to be sure, but with search=2, bad lines should be very rare. 
The test image on my web
page used search=1.

I thought of two possible solutions to this:

1.	Pick "random" points within each box such that it is impossible to
project a vertical or horizontal line through the box without it
intersecting a mortar line.

2.	Any mortar line longer than some maximum distance from its originating
point automatically splits at the max distance and sends out mortar lines
in either direction perpendicular to the original mortar line that continue
until they collide with some other mortar line.

I haven't come up with a trivial algorithm for either solution.

I'll think about using a noise function for the "random" data - my array of
random vectors isn't very elegant, even if it is fast.

extra note:  I tried out Megapov 0.7 today - My patch didn't work quite
right without adding &0xFFF to the arguments to Hash2d(int, int).  Strange.

-jim

[Jim Snow] Re: new pattern simulating a wall of interlockin... [9047 days 19 hours and 6 minutes ago]

Fri, 13 Jul 2001 07:31:10 GMT

Ryan Constantine <rco### [at] yahoocom> wrote in article
<3B4E660E.5D7C1577@yahoo.com>...
> cool except for one thing.  from your picture, it looks like it is a 2d
> pattern, not a 3d one.  bummer.

I think the algorithm can be generalized to 3d (but it might be beyond my
ability to do so), however there would be a problem with the mortar joints
parallel to the surface of the object occasionally being at the surface of
the object, resulting in an oddly textured block.  It might not be that big
of deal, but it would probably be annoying to anyone who just wants their
stone wall to look good from one side.

-jim

[Ron Parker] Re: new pattern simulating a wall of interlockin... [9047 days 22 hours and 34 minutes ago]

Fri, 13 Jul 2001 04:02:57 GMT

On Thu, 12 Jul 2001 20:07:58 -0700, Ryan Constantine wrote:
>cool except for one thing.  from your picture, it looks like it is a 2d
>pattern, not a 3d one.  bummer.

He mentions that in the code, actually.  I think the concept could be
extended to 3d without too much work, but it'd take some thought to
do it right.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

[Ryan Constantine] Re: new pattern simulating a wall of interlockin... [9047 days 23 hours and 33 minutes ago]

Fri, 13 Jul 2001 03:04:47 GMT

cool except for one thing.  from your picture, it looks like it is a 2d
pattern, not a 3d one.  bummer.

Jim Snow wrote:
> 
> I wrote a pattern simulating the appearance of a stone wall made of
> rectangular blocks of random size that interlock perfectly.  For an
> example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
> figured out how to integrate it into Pov-RAY so that I can call the pattern
> by name and pass in parameters, so the only way to play with it right now
> is to copy and paste my code into patterns.c and rename my "ashlar"
> function to match the name of another pattern, and comment out that
> pattern.
> 
> My code has been tested with Megapov .5, gcc, and Linux.
> 
> If someone wants to integrate it correctly into Pov-RAY, Megapov, or
> whatever, be my guest.  You can get my code at
> "http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?
> 
> -jim

[Bob H ] Re: new pattern simulating a wall of interlockin... [9048 days and 5 minutes ago]

Fri, 13 Jul 2001 02:32:10 GMT

Isn't the cells pattern much like this?  I'm not exactly sure myself.

Bob H.

"Jim Snow" <jsn### [at] csgeorgefoxedu> wrote in message
news:01c10ad7$8462d300$4b821c26@jmsWin95...
>
> I wrote a pattern simulating the appearance of a stone wall made of
> rectangular blocks of random size that interlock perfectly.  For an
> example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
> figured out how to integrate it into Pov-RAY so that I can call the
pattern
> by name and pass in parameters, so the only way to play with it right now
> is to copy and paste my code into patterns.c and rename my "ashlar"
> function to match the name of another pattern, and comment out that
> pattern.
>
> My code has been tested with Megapov .5, gcc, and Linux.
>
> If someone wants to integrate it correctly into Pov-RAY, Megapov, or
> whatever, be my guest.  You can get my code at
> "http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?
>
> -jim

[Ron Parker] Re: new pattern simulating a wall of interlockin... [9048 days and 20 minutes ago]

Fri, 13 Jul 2001 02:17:31 GMT

On 12 Jul 2001 21:35:58 -0400, Jim Snow wrote:
>If someone wants to integrate it correctly into Pov-RAY, Megapov, or
>whatever, be my guest.  You can get my code at
>"http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?

It's very interesting.  Have you done any calculations to determine what
the maximum search will have to be before you're guaranteed not to be on
a mortar line?  Have you considered using the Noise function instead of
a random array to determine the positions of the seed points?  That would
allow your "array" to be essentially infinite, if you could make it fit
into your algorithm, and it would constrain the positions of the seed 
points to an extent that you might be able to better predict what the 
maximum required search is.  

With those two changes, I think it would be a very useful pattern to 
have.  Also, I think you could get away with having just a single ratio
to determine the number of points horizontally vs. the number vertically,
since you can then scale the bricks to fit your space.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

[Jim Snow] new pattern simulating a wall of interlocking re... [9048 days 1 hour and 1 minute ago]

Fri, 13 Jul 2001 01:35:58 GMT

I wrote a pattern simulating the appearance of a stone wall made of
rectangular blocks of random size that interlock perfectly.  For an
example, look at "http://cs.georgefox.edu/~jsnow/pov.html".  I haven't
figured out how to integrate it into Pov-RAY so that I can call the pattern
by name and pass in parameters, so the only way to play with it right now
is to copy and paste my code into patterns.c and rename my "ashlar"
function to match the name of another pattern, and comment out that
pattern.

My code has been tested with Megapov .5, gcc, and Linux.

If someone wants to integrate it correctly into Pov-RAY, Megapov, or
whatever, be my guest.  You can get my code at
"http://cs.georgefox.edu/~jsnow/ashlar.c".  Anyone interested?

-jim

[David] Re: mpeg format [9089 days 14 hours and 31 minutes ago]

Fri, 1 Jun 2001 12:06:18 GMT

In article <MPG### [at] NEWSPOVRAYORG>, "Sander"
<san### [at] stolscom> wrote:
 
> http://bmrc.berkeley.edu/frame/research/mpeg/index.html
> 
> http://www.wotsit.org/search.asp?page=2&s=animated
> 
> Perhaps these may help you on your way. I am interested in what you
> achieve!!

Thank you very much.  These are very helpful!


-- 
David
smu### [at] ameritechnet
ICQ#: 118347772

[Sander] Re: mpeg format [9089 days 20 hours and 7 minutes ago]

Fri, 1 Jun 2001 06:30:30 GMT

In article <200### [at] erwinlargegeekcom>, David 
says...
> I am trying to write a program that encodes TGA files into a MPEG
> animation.  The only thing I need is the format of an MPEG animation
> file.  Anyone know where I can get this at?  Thanks in advance!
> 
> 
http://bmrc.berkeley.edu/frame/research/mpeg/index.html

http://www.wotsit.org/search.asp?page=2&s=animated

Perhaps these may help you on your way. I am interested in what you 
achieve!!
-- 
Regards,  Sander

[David] mpeg format [9090 days 3 hours and 15 minutes ago]

Thu, 31 May 2001 23:22:49 GMT

I am trying to write a program that encodes TGA files into a MPEG
animation.  The only thing I need is the format of an MPEG animation
file.  Anyone know where I can get this at?  Thanks in advance!

-- 
David
smu### [at] ameritechnet
ICQ#: 118347772

[Ron Parker] values.h for Diego Krota [9104 days 11 hours and 7 minutes ago]

Thu, 17 May 2001 15:30:00 GMT

[] POVRAY-Rendering in networks? [9113 days 7 hours ago]

Tue, 8 May 2001 19:36:50 GMT

Ist there a programm or so forcing Povray to render big jobs on several PCs
(Windows NT) in a Network (somethig like a "render-farm")?

[Vahur Krouverk] Makefile for borland free compiler [9134 days 9 hours and 49 minutes ago]

Tue, 17 Apr 2001 16:48:42 GMT

See notes in following post for details:

Subject:    Re: free borland
Date:       Tue, 17 Apr 2001 18:47:44 +0200
From:       Vahur Krouverk <vah### [at] aetecee>
Newsgroups: povray.programming

[Pabs] Re: Buttons for web design [9153 days 20 hours and 49 minutes ago]

Thu, 29 Mar 2001 05:48:39 GMT

Rick [Kitty5] wrote:

>> Um what about the orthographic cam??
> well you could, but moray has no ortho cam suppt
I didn't know we were talking about moray? - but anyways
Say what??? - you sure?
Aren't the x,y&z views ortho - they certainly look it
I guess Lutz et. al. haven't needed to allow the cam to use ortho

Bye,
Pabs

[Rick [Kitty5]] Re: Buttons for web design [9154 days 13 hours and 4 minutes ago]

Wed, 28 Mar 2001 13:33:45 GMT

> > just place your cam a fair distance away so
> > the button appears flat
> Um what about the orthographic cam??

well you could, but moray has no ortho cam suppt


--
Rick

POV-Ray News & Resources - http://Povray.co.uk
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

[Pabs] Re: Buttons for web design [9154 days 20 hours and 19 minutes ago]

Wed, 28 Mar 2001 06:17:51 GMT

Rick [Kitty5] wrote:

> just place your cam a fair distance away so
> the button appears flat
Um what about the orthographic cam??

[The "D"] Re: Buttons for web design [9156 days 21 hours and 41 minutes ago]

Mon, 26 Mar 2001 04:56:20 GMT

[reply directed to povray.newusers]
Roland Mösl <fou### [at] pegeorg> wrote in message
news:3abcaabe$1@news.povray.org...
> "Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
> news:3abca826$1@news.povray.org...
> >
> > > Has somebody some source text
> > > to create buttons used for web pages
> > > created by Povray?
> >
> > I have done this in the past, just place your cam a fair distance away
so
> > the button appears flat
>
> I use on most of my web sites a recorder style button system with
> fast reverse ( jump previouse index )
> reverse ( jump previouse page
> forward ( jump next page )
> fast forward ( jump next index page )
>
> All with mosue over.
> Would like to have one source file,
> where I have only to change color parameters,
> and this makes all the graphics 2 pictures per
> button (normal, mouse over)
>
> Was Your project in this direction?
>
>
> --
> Roland Mösl
> http://pege.org Clear targets for a confused civilization
> http://BeingFound.com Web Design starts at the search engine
>
>
>

[Chris Huff] Re: Buttons for web design [9158 days 10 hours and 31 minutes ago]

Sat, 24 Mar 2001 16:06:06 GMT

In article <3abc4845@news.povray.org>, "Roland Mösl" <fou### [at] pegeorg> 
wrote:

> Has somebody some source text
> to create buttons used for web pages
> created by Povray?

This group, povray.binaries.programming, is for posting binary files 
related to programming and the POV-Ray source code. Your question has 
nothing to do with programming and you didn't post a binary, the 
povray.general or povray.newusers group would have been a better place.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

[Rick [Kitty5]] Re: Buttons for web design [9158 days 10 hours and 51 minutes ago]

Sat, 24 Mar 2001 15:46:05 GMT

> Was Your project in this direction?

I have done a couple of site GUI's in moray \ povray


--
Rick

POV-Ray News & Resources - http://povray.co.uk
Kitty5 WebDesign - http://kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

[] Re: Buttons for web design [9158 days 12 hours and 27 minutes ago]

Sat, 24 Mar 2001 14:10:06 GMT

"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:3abca826$1@news.povray.org...
>
> > Has somebody some source text
> > to create buttons used for web pages
> > created by Povray?
>
> I have done this in the past, just place your cam a fair distance away so
> the button appears flat

I use on most of my web sites a recorder style button system with
fast reverse ( jump previouse index )
reverse ( jump previouse page
forward ( jump next page )
fast forward ( jump next index page )

All with mosue over.
Would like to have one source file,
where I have only to change color parameters,
and this makes all the graphics 2 pictures per
button (normal, mouse over)

Was Your project in this direction?


--
Roland Mösl
http://pege.org Clear targets for a confused civilization
http://BeingFound.com Web Design starts at the search engine

[Rick [Kitty5]] Re: Buttons for web design [9158 days 12 hours and 38 minutes ago]

Sat, 24 Mar 2001 13:59:02 GMT

> Has somebody some source text
> to create buttons used for web pages
> created by Povray?

I have done this in the past, just place your cam a fair distance away so
the button appears flat


--
Rick

POV-Ray News & Resources - http://povray.co.uk
Kitty5 WebDesign - http://kitty5.com
Hi-Impact web site design & database driven e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

[] Buttons for web design [9158 days 19 hours and 27 minutes ago]

Sat, 24 Mar 2001 07:09:57 GMT

Has somebody some source text
to create buttons used for web pages
created by Povray?


--
Roland Mösl
http://pege.org Clear targets for a confused civilization
http://BeingFound.com Web Design starts at the search engine

[Peter Warren] Re: Games? [9181 days 17 hours and 26 minutes ago]

Thu, 1 Mar 2001 09:11:47 GMT

>Allegro, that might not be so hard :)
Allegro? You kids today. With your wheel and fire.
That wheel is going to put your eye out. And fire...
all you do all day is sit and stare at it all day...

pw.etc

[Jérôme Grimbert] Re: We need a new 'render' statement [9182 days 17 hours and 21 minutes ago]

Wed, 28 Feb 2001 09:16:30 GMT

Bryan Valencia wrote:
> 
> Let's say you wrote an AI routine that made a ship attack targets or implemented
> gravity or wind velocity.
> 
> You could call the exe repeatedly and it could store it's last state.
> 

I would rather have the exe called outside of POV and store each result into
a distinct file (so that distributed rendering could be easy).
The filename could of course be based on the clock value and
the pov-scene would simply #include the one for the current clock.

[Bryan Valencia] Re: We need a new 'render' statement [9183 days 6 hours and 53 minutes ago]

Tue, 27 Feb 2001 19:44:03 GMT

Let's say you wrote an AI routine that made a ship attack targets or implemented
gravity or wind velocity.

You could call the exe repeatedly and it could store it's last state.


Hassoun wrote:

> Hi
> i am familiar with the use of the clock variable for animation, but
> would you please explain the advantages of calling an EXE during an
> animation. how would it help?
>
> thanks
> Hassoun
>
> Bryan Valencia wrote:
> >
> > Are you using the Windows Version?
> >
> > If so, you can set up animations using the clock variable, and you can also
> > call an EXE during an animation loop.
> >
>
> > --
> > Bryan Valencia
> > Software Services
> > http://www.209software.com
> > mailto:bry### [at] 209softwarecom

[Geoff Wedig] Re: Making the Leap: Compiling POV for the first... [9187 days 7 hours and 29 minutes ago]

Fri, 23 Feb 2001 19:08:31 GMT

Vahur Krouverk <vah### [at] aetecee> wrote:

> Geoff Wedig wrote:
>> Unfortunately, Kai doesn't compile the code correctly.  I'm getting errors
>> that it doesn't find the Frame global variable in atmos.c, the first .c file
>> to be compiled.  That's an extern out of povray.h, which is included in
>> atmos.c, so I don't know why it's not finding it.  Does anyone have any
>> ideas why this might be going weird on me?

> Don't know the reason, but try to turn (all) warnings on, maybe they
> could give hint about problem?
> And be sure to compile source as C files, not as C++ files (I don't
> know, how KAI determines type of source file, look from manual/options).
> C and C++ are not quite same...
> HTH

I doubt this is the problem, in this case, but turning on more messages is
certainly a good idea.  Time to delve into the docs....

Geoff

[Vahur Krouverk] Re: Making the Leap: Compiling POV for the first... [9187 days 9 hours and 23 minutes ago]

Fri, 23 Feb 2001 17:14:07 GMT

Geoff Wedig wrote:
> Unfortunately, Kai doesn't compile the code correctly.  I'm getting errors
> that it doesn't find the Frame global variable in atmos.c, the first .c file
> to be compiled.  That's an extern out of povray.h, which is included in
> atmos.c, so I don't know why it's not finding it.  Does anyone have any
> ideas why this might be going weird on me?

Don't know the reason, but try to turn (all) warnings on, maybe they
could give hint about problem?
And be sure to compile source as C files, not as C++ files (I don't
know, how KAI determines type of source file, look from manual/options).
C and C++ are not quite same...
HTH

[Geoff Wedig] Making the Leap: Compiling POV for the first time [9187 days 9 hours and 56 minutes ago]

Fri, 23 Feb 2001 16:41:46 GMT

Well, I decided to see if I could compile POV myself.  This was instituted
by two things:

1. A really slow scene that I'd like to get faster
2. Getting linux up and running on my home system.

Now, I know the linux version is available, and what's more, it compiles
fine on my system right out of the box with gcc, but I have access to the
KAI C++ compiler through my work and I thought I'd try it and see which was
faster.  I've been very impressed with KAI in the past, so I thought I'd see
what kind of results I could get.

Unfortunately, Kai doesn't compile the code correctly.  I'm getting errors
that it doesn't find the Frame global variable in atmos.c, the first .c file
to be compiled.  That's an extern out of povray.h, which is included in
atmos.c, so I don't know why it's not finding it.  Does anyone have any
ideas why this might be going weird on me?

Thanks for any help,

Geoff

[Thomas] PVMPOV for win32 [9187 days 13 hours and 56 minutes ago]

Fri, 23 Feb 2001 12:41:43 GMT

See comments in p.u-p

 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//atmosph.c -o ./atmosph.obj
atmosph.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//bbox.c -o ./bbox.obj
bbox.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//bcyl.c -o ./bcyl.obj
bcyl.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//bezier.c -o ./bezier.obj
bezier.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//blob.c -o ./blob.obj
blob.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//boxes.c -o ./boxes.obj
boxes.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//bsphere.c -o ./bsphere.obj
bsphere.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//camera.c -o ./camera.obj
camera.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//chi2.c -o ./chi2.obj
chi2.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//colour.c -o ./colour.obj
colour.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//cones.c -o ./cones.obj
cones.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//csg.c -o ./csg.obj
csg.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//discs.c -o ./discs.obj
discs.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//express.c -o ./express.obj
express.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//fractal.c -o ./fractal.obj
fractal.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//gif.c -o ./gif.obj
gif.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//gifdecod.c -o ./gifdecod.obj
gifdecod.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//hcmplx.c -o ./hcmplx.obj
hcmplx.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//hfield.c -o ./hfield.obj
hfield.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//iff.c -o ./iff.obj
iff.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//image.c -o ./image.obj
image.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//interior.c -o ./interior.obj
interior.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//lathe.c -o ./lathe.obj
lathe.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//lbuffer.c -o ./lbuffer.obj
lbuffer.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//lighting.c -o ./lighting.obj
lighting.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//matrices.c -o ./matrices.obj
matrices.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//media.c -o ./media.obj
media.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//mem.c -o ./mem.obj
mem.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//mesh.c -o ./mesh.obj
mesh.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//normal.c -o ./normal.obj
normal.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//objects.c -o ./objects.obj
objects.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//octree.c -o ./octree.obj
octree.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//optin.c -o ./optin.obj
optin.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//optout.c -o ./optout.obj
optout.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//parse.c -o ./parse.obj
parse.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//parstxtr.c -o ./parstxtr.obj
parstxtr.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//pattern.c -o ./pattern.obj
pattern.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//pgm.c -o ./pgm.obj
pgm.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//pigment.c -o ./pigment.obj
pigment.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//planes.c -o ./planes.obj
planes.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//png_pov.c -o ./png_pov.obj
png_pov.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//point.c -o ./point.obj
point.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//poly.c -o ./poly.obj
poly.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//polygon.c -o ./polygon.obj
polygon.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//polysolv.c -o ./polysolv.obj
polysolv.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//povray.c -o ./povray.obj
povray.c
..//povray.c(326) : warning C4033: 'main' must return a value
..//povray.c(426) : warning C4715: 'main' : not all control paths return
a value
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//ppm.c -o ./ppm.obj
ppm.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//prism.c -o ./prism.obj
prism.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//quadrics.c -o ./quadrics.obj
quadrics.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//quatern.c -o ./quatern.obj
quatern.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//rad_data.c -o ./rad_data.obj
rad_data.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//radiosit.c -o ./radiosit.obj
radiosit.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//ray.c -o ./ray.obj
ray.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//render.c -o ./render.obj
render.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//sor.c -o ./sor.obj
sor.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//spheres.c -o ./spheres.obj
spheres.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//super.c -o ./super.obj
super.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//targa.c -o ./targa.obj
targa.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//texture.c -o ./texture.obj
texture.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//tokenize.c -o ./tokenize.obj
tokenize.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//torus.c -o ./torus.obj
torus.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//triangle.c -o ./triangle.obj
triangle.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//truetype.c -o ./truetype.obj
truetype.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//txttest.c -o ./txttest.obj
txttest.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//userio.c -o ./userio.obj
userio.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//vbuffer.c -o ./vbuffer.obj
vbuffer.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//vlbuffer.c -o ./vlbuffer.obj
vlbuffer.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib ..//warps.c -o ./warps.obj
warps.c
 cl /c -DHASSTDLIB -DWIN32 -DSYSVBFUNC -DSYSVSTR  -DHASERRORVARS
-DNOWAIT3 -DNOGETDTBLSIZ -DNOUNIXDOM  -DNOTMPNAM -DMAXHOSTNAMELEN=64
-DMAXPATHLEN=64  -DNEEDSFFS /nologo /GX /O2  /D "_CONSOLE"
-ID:\PROGRA~1\MICROS~3\VC98\include -Id:\PROGRA~1\PVM3.4\include
-Id:\PROGRA~1\PVM3.4\tracer -Id:\PROGRA~1\PVM3.4\src  -I. -I.. -I../
-I..//unix -I..//libpng -I..//zlib -Id:\PROGRA~1\PVM3.4/include pvm.c -o
./pvm.obj
pvm.c
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(22) : error C2061: syntax
error : identifier 'BYTE'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(23) : error C2061: syntax
error : identifier 'SrcAddr'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(23) : error C2059: syntax
error : ';'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(23) : error C2059: syntax
error : '['
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(26) : error C2061: syntax
error : identifier 'WORD'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(27) : error C2061: syntax
error : identifier 'Type'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(27) : error C2059: syntax
error : ';'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(28) : error C2059: syntax
error : '}'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(29) : error C2061: syntax
error : identifier 'Info'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(29) : error C2059: syntax
error : ';'
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(29) : error C2059: syntax
error : '['
D:\PROGRA~1\MICROS~3\VC98\include\frame.h(30) : error C2059: syntax
error : '}'

[ remainder of message truncated in this digest view due to length ]

[Thomas Charron] Re: Games? [9218 days 7 hours and 13 minutes ago]

Tue, 23 Jan 2001 19:23:59 GMT

Reading this thread, take a gander at http://crystal.linuxgames.com/.
It provides a high level system that allows games to be run using OpenGL,
glide, DirectX, etc..  It abstracts the drawing interface for you.  Heck,
they're even working on a version that would allow games based on their
engine to run natively on the PS2..

"H.E. Day" <art### [at] fcinet> wrote in message
news:3876B5B3.C40460F0@fci.net...
> I'm just wondering, does anyone here have any interest in game
> programming?  I've got a few ideas, and I'd like to field them
> Thanks!
>
> --
> H.E. Day
> ------------------------
> Science is merely a method of gathering data and information.
> Science *cannot* prove facts.
> It can only provide theories that fit given data.
> Technology is merely Science applied to common situations.
> Technology is used for both good and evil.
> Society is a framework mostly dependent on the willing participation of
> it
> subjects.
> Kingdoms and dominions come and go, none are eternal.
> In the end, Society, Technology, and Science do not matter.  Only the
> actions
> and choices of the individual will matter. <><
>
>

[Thomas Charron] Re: Games? [9218 days 7 hours and 13 minutes ago]

Tue, 23 Jan 2001 19:23:59 GMT

Reading this thread, take a gander at http://crystal.linuxgames.com/.
It provides a high level system that allows games to be run using OpenGL,
glide, DirectX, etc..  It abstracts the drawing interface for you.  Heck,
they're even working on a version that would allow games based on their
engine to run natively on the PS2..

"H.E. Day" <art### [at] fcinet> wrote in message
news:3876B5B3.C40460F0@fci.net...
> I'm just wondering, does anyone here have any interest in game
> programming?  I've got a few ideas, and I'd like to field them
> Thanks!
>
> --
> H.E. Day
> ------------------------
> Science is merely a method of gathering data and information.
> Science *cannot* prove facts.
> It can only provide theories that fit given data.
> Technology is merely Science applied to common situations.
> Technology is used for both good and evil.
> Society is a framework mostly dependent on the willing participation of
> it
> subjects.
> Kingdoms and dominions come and go, none are eternal.
> In the end, Society, Technology, and Science do not matter.  Only the
> actions
> and choices of the individual will matter. <><
>
>

[Dearmad] Re: Games? [9221 days and 15 minutes ago]

Sun, 21 Jan 2001 02:21:58 GMT

WOW!  Excellent stuff!  All models in there are from POV? 
That is awesome- I don't have time yet, but I'll d/l and
check out the pre-alpha soon.

Again, awesome work sticking with a project that well and
seeing it to where you've got it.  I hope you finish it.
-- 
http://www.teleport.com/~dearmad
But why bother?  I'm not interesting.

[Bogdan] Re: Games? [9221 days 1 hour and 39 minutes ago]

Sun, 21 Jan 2001 00:58:15 GMT

Hi
I am makeing a 2D RTS Game: "Hostile Encounter"
and using POV Ray to render 3D modeles as 2D bitmaps

checkit out:
www.angelfire.com/games3/bogdanontanu
or
www.gdarchive.net/bogdanontanu/index.html


after this one i will make a 3D one...hopefully also with the help of
POV :)


"H.E. Day" wrote:
> 
> I'm just wondering, does anyone here have any interest in game
> programming?  I've got a few ideas, and I'd like to field them
> Thanks!
> 
> --
> H.E. Day
> ------------------------
> Science is merely a method of gathering data and information.
> Science *cannot* prove facts.
> It can only provide theories that fit given data.
> Technology is merely Science applied to common situations.
> Technology is used for both good and evil.
> Society is a framework mostly dependent on the willing participation of
> it
> subjects.
> Kingdoms and dominions come and go, none are eternal.
> In the end, Society, Technology, and Science do not matter.  Only the
> actions
> and choices of the individual will matter. <><

[Thomas Davidson] How? [9284 days 5 hours and 2 minutes ago]

Sat, 18 Nov 2000 21:35:43 GMT

Please excuse this quite probably stupid quesiton, but how do you go about
maing .pob files?

[Matt Giwer] pov code to html [9295 days 17 hours and 33 minutes ago]

Tue, 7 Nov 2000 09:04:03 GMT

The attached is a a cheap hack on code2html produced by a respectible
perl programmer. It should work on any machine with perl installed. 

	It provides basic syntax highlighting when viewed in a browser. I have
inlcuded the original code2html.1 man page for other features (which may
or may not work with this hack) and to give an idea of what the original
can do. 

	The original full open source files is available at the website in the
second attachment.

-- 
Never put temptation in the way of a politician. 
Politicians view temptation as opportunity.
	-- The Iron Webmaster, 269

[Simon Lemieux] Re: Games? [9312 days 8 hours and 44 minutes ago]

Sat, 21 Oct 2000 17:53:34 GMT

> I'm just wondering, does anyone here have any interest in game
> programming?  I've got a few ideas, and I'd like to field them
> Thanks!

I know this is a pretty old thread, but I just subscribed to this newsgroup and
so, I know very well how to program in C++ and use OpenGL, I've made a few
really cool and really fast screen-saver like 3D programs with OpenGL.

I could easily make a sprite game( with little 3D, orthographic camera, etc..),
I could also make a very nice 3D space rally, if you provide the textures for
example...

OpenGL is also very good for making GUI... menus and such are very easy made and
can even be accelerated by a 3Dfx!....

If anyone is still interested, I am!

Simon

-- 
+-------------------------+----------------------------------+
| Simon Lemieux           | Website : http://www.666Mhz.net  |
| Email : Sin### [at] 666Mhznet | POV-Ray, OpenGL, C++ and more... |
+-------------------------+----------------------------------+

[Vahur Krouverk] Colour space conversion code. [9369 days 18 hours and 49 minutes ago]

Fri, 25 Aug 2000 07:48:13 GMT

Hello!

This is my patched version of colour.c and colour.h. This patched
version includes conversion routine between RGB, HSL, HSV, XYZ, xyY, YIQ
colour spaces. 

Please note, that I changed return value of RGBtoHue to return
"standard" hue value and added function RGBtoSpecter for returning
"spectral value" of colour hue. If someone wants to use colour.c in
MegaPov, then files lighting.c and postproc.c should be changed
accordingly (replace RGBtoHue with RGBtoSpecter).

Another note: these files are in Unix format (includes only newline
character in the end of file).

[Mike] new uv mapping patch (Win) [600kb] [9377 days 1 hour and 40 minutes ago]

Fri, 18 Aug 2000 00:57:07 GMT

This is a modified MegaPOV with support for type 2 and type 3 bicubic
patches.  uv_vectors has been changed to take four components instead of
two, therefore it is not backwards compatible with the previous syntax.

I'm releasing this so that others can use some of the scenes I have been
making.

-Mike

[J Grimbert] Kepler (modified source from 3.1g and doc) [65 +... [9418 days 10 hours and 7 minutes ago]

Fri, 7 Jul 2000 16:30:20 GMT

Here is the patch for adding the kepler CSG construct.
All modification are tagged with

/* JG09 >> */

/* << JG09 */

(well, I hope they are all).
There is two new files : kepler.c and kepler.h, so one need to
modify the makefile.

An improvement of the bounding box would certainly a good thing.

Also, a separate documentation.
One need to render the *.ini (with the kepler patch applied) to
get all the pictures. (but at least the zip is reduced from 640K to
15K!)

[George Peter Staplin] Re: Games? [9422 days 3 hours and 56 minutes ago]

Mon, 3 Jul 2000 22:41:41 GMT

Andrea Ryan wrote:
> 
> >
> > You know we can render stuff better than that! ;)
> 
> Why not render a lot of pictures with POV-Ray and make a Myst-like game using
> the arrow keys in place of the mouse?  I would just need to have code for
> displaying pictures (PNG) and getting input from the arrow keys.  I would
> also need to figure out how to 'link' the pictures together.
> Brendan Ryan
> 
> Here's some pseudo code (which is incomplete).
> 
> Open picture file
> If up arrow key pressed
> Subtract one from picture id number (filename)
> Close picture file
> Open next picture file with new id number
> 
> To go left or right, use second id number.  The filename looks like this:
> 1st_id_no_s_2nd_id_no.png where s is a letter.

I wrote a game with a friend that was similar to Myst called the Island
Project.  We used JPEG images for the scenes, and PNG images with
transparency for the metal border around the scene image and for the
cursor.  One of the demos that I wrote even had movies and sound.  The
only problem is that I wrote it using a high level toolkit that was slow
compared to Myst when displaying new images.  Sadly we didn't finish the
game.  

I now have a lot more experience with lower level programming, so if you
could use the help creating a game for Unix, or perhaps Windows, I am
interested in devoting some spare time.

http://www.xmission.com/~georgeps/island/screenshot.jpg
http://www.xmission.com/~georgeps/island/screenshot2.jpg
http://www.linuxave.net/~yura/island/index.htm

-- 
----------------------------------
George Peter Staplin
http://www.xmission.com/~georgeps/
----------------------------------

[woormie] Re: linux editor [9435 days 10 hours and 3 minutes ago]

Tue, 20 Jun 2000 16:34:25 GMT

Pabs wrote:
> 
> mik### [at] hotmailcom wrote:
> 
> > I am wondering why the windows verision is the only one with the built
> > in editor. It would be nice if the linux version could have the
> > windows editor also. A SVGA and Xwindows version would be nice. This
> > editor should be in the MAC povray also. Also a BE version of Povray
> > should be in the list of official ports.
> 
> From what I can see from the screenshots at
> http://mac.povray.org/screenshot.html it loos like there actually is an
> editor for MacPOV-Ray
> 
> It would be good for the linux version to have a built-in editor, although
> it seems (from p.unix) that most people just use x/emacs with pov-mode as
> their editor.

x/emacs with pov-mode is very nice (I have to say that as maintainer;),
but 
really, you get the pretty much the same stuff as with the
windows-version 
(and the macversion as seen in those screenshots). I'm working on
enhancing
the povmode quite a bit, and will try to get everything working by the
end
of summer (winter for you who walk upside down). The most noticable new
feature
will be a major change to the syntax highlighting, pov-mode will get
it's own
font-lock-faces. I will also try to add buttons to the buttonbar in
xemacs, but
thats not a priority.

/Peter, pov-mode maintainer and hungry.

[Pabs] Re: linux editor [9436 days and 1 minute ago]

Tue, 20 Jun 2000 02:36:23 GMT

mik### [at] hotmailcom wrote:

> I am wondering why the windows verision is the only one with the built
> in editor. It would be nice if the linux version could have the
> windows editor also. A SVGA and Xwindows version would be nice. This
> editor should be in the MAC povray also. Also a BE version of Povray
> should be in the list of official ports.

From what I can see from the screenshots at
http://mac.povray.org/screenshot.html it loos like there actually is an
editor for MacPOV-Ray

It would be good for the linux version to have a built-in editor, although
it seems (from p.unix) that most people just use x/emacs with pov-mode as
their editor.

Pabs

[Hartmut Wagener] Re: linux editor [9436 days 3 hours and 2 minutes ago]

Mon, 19 Jun 2000 23:34:54 GMT

Yes, that is one reason that i don´t use the linux-version ...
And best complete for X-windows ...

Hartmut
mik### [at] hotmailcom schrieb in Nachricht
<394e6000.13957606@news.povray.org>...
>I am wondering why the windows verision is the only one with the built
>in editor. It would be nice if the linux version could have the
>windows editor also. A SVGA and Xwindows version would be nice. This
>editor should be in the MAC povray also. Also a BE version of Povray
>should be in the list of official ports.

[mike1jeremie] linux editor [9436 days 8 hours and 35 minutes ago]

Mon, 19 Jun 2000 18:02:35 GMT

I am wondering why the windows verision is the only one with the built
in editor. It would be nice if the linux version could have the
windows editor also. A SVGA and Xwindows version would be nice. This
editor should be in the MAC povray also. Also a BE version of Povray
should be in the list of official ports.

[Andrea Ryan] Re: Games? [9487 days and 26 minutes ago]

Sun, 30 Apr 2000 02:11:14 GMT

>
> You know we can render stuff better than that! ;)

Why not render a lot of pictures with POV-Ray and make a Myst-like game using
the arrow keys in place of the mouse?  I would just need to have code for
displaying pictures (PNG) and getting input from the arrow keys.  I would
also need to figure out how to 'link' the pictures together.
Brendan Ryan

Here's some pseudo code (which is incomplete).

Open picture file
If up arrow key pressed
Subtract one from picture id number (filename)
Close picture file
Open next picture file with new id number

To go left or right, use second id number.  The filename looks like this:
1st_id_no_s_2nd_id_no.png where s is a letter.

[Chris Huff] Re: post_process filters source code - filters.z... [9487 days 7 hours and 32 minutes ago]

Sat, 29 Apr 2000 19:05:36 GMT

Due to problems with the .zip version, here is the .sit version. If you 
don't have StuffIt Expander, you can get it here:
http://www.aladdinsys.com/expander/expander_win_login.html

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

[Chris Huff] Re: post_process filters source code - filters.z... [9488 days 9 hours and 40 minutes ago]

Fri, 28 Apr 2000 16:57:12 GMT

In article <chrishuff_99-39B6D6.10581528042000@news.povray.org>, Chris 
Huff <chr### [at] yahoocom> wrote:

> Sorry about the delays, but here is the changed source code. I also 
> included some demo files and some documentation(part of the reason for 
> the delays).

To fix the "upside down pigment" problem with patterned_blur, add, 
multiply, and exponent, change this line in the functions 
doPostPatternBlur(), doPostAdd(), doPostMult(), and doPostExp():
        Loc[0] = (DBL)x/width;
        Loc[1] = (DBL)y/height;
to this:
        Loc[0] = (DBL)x/width;
        Loc[1] = 1-((DBL)y/height);

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

[Chris Huff] post_process filters source code - filters.zip (... [9488 days 10 hours and 42 minutes ago]

Fri, 28 Apr 2000 15:55:28 GMT

Sorry about the delays, but here is the changed source code. I also 
included some demo files and some documentation(part of the reason for 
the delays).

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

[Chris Huff] Transform patch changed source files - transpat.... [9491 days 23 hours and 38 minutes ago]

Tue, 25 Apr 2000 02:58:55 GMT

Because of the large number of changes I have made, I am including the 
whole files instead of listing the changes. However, I have also been 
working on some other stuff...if you see something about "blur_matrix", 
just ignore it. I think I weeded all of that stuff out, though. The 
stuff relevant to the transform patch is pretty clearly identifiable.

This patch does two things:
1: it allows transform {...} blocks to be placed in objects, textures, 
etc. There might be a problem with media densities, though, that portion 
of the code doesn't seem to make any sense. It may be a bug.
Anyway, this means you can do things like this:
object {
    transform {
        transform identifier, rotate, translate, scale, etc...
    }
}
The old syntax of "transform TRANSFORM_IDENTIFIER" is still supported.

2: it allows transforms to be inverted with the "inverse" keyword. Like 
this:
object {
    transform {Trans}
    transform {Trans inverse}// this reverses the above transform
}

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

[Chris Huff] Blurred transparence patch - BlurTrans.zip (1/1) [9581 days 3 hours and 42 minutes ago]

Wed, 26 Jan 2000 22:55:25 GMT

Here it is, the new version of my blurred transparence patch. It is 
quite a bit different from my previous patch in both syntax and the way 
it is coded. This version is based on the MegaPOV 0.3 source, so you 
need to have a working compile of MegaPOV 0.3 in order to use it.
I haven't had the time to write any decent documentation, but this is 
the syntax for the blurred transparence patch, it should be pretty 
obvious:

finish {
    transparence {
        transparence_blur AMOUNT
        blur_samples SAMPLES
    }
}
global_settings {
    transparence {
        blur_samples SAMPLES
        blur_max_trace LEVEL
        blur_max_adc AMOUNT
    }
}


These are the files I had to modify and a brief description of the 
changes in each one.

frame.h (Finish_Struct data)
tokenize.c (added tokens)
parse.h (added tokens)
parstxtr.c (added parse code to Parse_Finish)
parse.c (global_settings parse code)
povray.h (added Transparence_Blur_Max, Transparence_Blur_Max_ADC 
variables for global_settings options)
povray.c (added initializers for global_settings options)
texture.c (added initializers for finish variables)
lighting.c (modified Refract(), Refract_Guts(), BacktraceRefract(), 
compute_backtrace_texture(), etc. to allow blur, and added 
Blurry_Trace(). Photons, motion blur, etc should work fine, but are 
untested.)


Note: In layered textures, only the top layer will blur transparency. I 
will try to fix this in a later version, but it shouldn't be a serious 
problem for now.
Also, there is a "fix" for something that might be a bug with the 
max_adc global setting for blurred reflection. It was stored as an 
integer, and I think it should be a float. Those changes are in parse.c 
and povray.h.
Also, this patch has just barely been tested. I don't think there are 
any bugs left(other than the thing with layered textures), but there are 
no guarantees.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

[H E Day] Re: Games? [9596 days 20 hours and 33 minutes ago]

Tue, 11 Jan 2000 06:04:23 GMT

Fraid not.  I know I've tried.  For about 5 years I've tried.  These be mucho
better.


H.E. Day

TonyB wrote:

> >Oh, and one more thing.  I've found some really cool explosion to put in
> >this concept. Look at:
> >http://www.artbeats.com/products/Explosions4/RE4detail3.html
> >
> >Heh, heh... Pyro baby!
>
> You know we can render stuff better than that! ;)

--
H.E. Day
------------------------
Science is merely a method of gathering data and information.
Science *cannot* prove facts.
It can only provide theories that fit given data.
Technology is merely Science applied to common situations.
Technology is used for both good and evil.
Society is a framework mostly dependent on the willing participation of it
subjects.
Kingdoms and dominions come and go, none are eternal.
In the end, Society, Technology, and Science do not matter.  Only the actions

and choices of the individual will matter. <><