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.

Post a reply to this message

Attachments:
Download 'povray-3.8.0-x.povr_1984d6ea.tar.gz' (1771 KB)

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.

Post a reply to this message

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

Post a reply to this message

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.)

Post a reply to this message

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

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message

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.

Post a reply to this message