POV-Ray : Newsgroups : povray.binaries.programming : An updated povr tarball for Unix/Linux. 6e4ed6c2 Server Time
18 Apr 2024 16:41:50 EDT (-0400)
  An updated povr tarball for Unix/Linux. 6e4ed6c2 (Message 1 to 2 of 2)  
From: William F Pokorny
Subject: An updated povr tarball for Unix/Linux. 6e4ed6c2
Date: 26 Oct 2021 11:11:56
Message: <61781abc@news.povray.org>
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/

or

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

Or <install>/INSTALL.txt

Bill P.


Post a reply to this message


Attachments:
Download 'povray-3.8.0-x.povr_6e4ed6c2.tar.gz' (1821 KB)

From: jr
Subject: Re: An updated povr tarball for Unix/Linux. 6e4ed6c2
Date: 4 Nov 2021 07:05:00
Message: <web.6183bdae71acfbfdd6c295506cde94f1@news.povray.org>
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.


Post a reply to this message

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