![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: New black_hole type of 1 proposed as github pull request #86.
Date: 9 Sep 2016 18:12:50
Message: <57d333e2$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Notice & image for those following here. Violet spheres mark the center
of the inward pulling black holes. Orange marks the inverse, outward
pushing black holes. One orange is below the plane in the lowest center
case.
Original github checks clean, but fail after manually bumping up the
version numbers in the branch. Unsure why.
Bill P.
Post a reply to this message
Attachments:
Download 'newblack_hole_type1.jpg' (122 KB)
Preview of image 'newblack_hole_type1.jpg'
![newblack_hole_type1.jpg](/povray.beta-test/attachment/%3C57d333e2%241%40news.povray.org%3E/newblack_hole_type1.jpg?ttop=441402&toff=150&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: New black_hole type of 1 proposed as github pull request #86.
Date: 10 Sep 2016 06:45:05
Message: <57d3e431@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 10.09.2016 um 00:12 schrieb William F Pokorny:
> Notice & image for those following here. Violet spheres mark the center
> of the inward pulling black holes. Orange marks the inverse, outward
> pushing black holes. One orange is below the plane in the lowest center
> case.
It is quite obvious that your contributions are currently focused on
isosurfaces; but since warps are pattern features, which are first and
foremost texture tools, maybe an illustration of the new warps' effect
on textures would also be of interest ;)
> Original github checks clean, but fail after manually bumping up the
> version numbers in the branch. Unsure why.
It conflicts with changes made to the master branch after you branched
off (the version numbers, evidently).
I must confess that version number handling is something that seriously
bothers me, with a good solution still waiting to be found.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: New black_hole type of 1 proposed as github pull request #86.
Date: 10 Sep 2016 08:47:18
Message: <57d400d6@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 09/10/2016 06:45 AM, clipka wrote:
> Am 10.09.2016 um 00:12 schrieb William F Pokorny:
>> Notice & image for those following here. Violet spheres mark the center
>> of the inward pulling black holes. Orange marks the inverse, outward
>> pushing black holes. One orange is below the plane in the lowest center
>> case.
>
> It is quite obvious that your contributions are currently focused on
> isosurfaces; but since warps are pattern features, which are first and
> foremost texture tools, maybe an illustration of the new warps' effect
> on textures would also be of interest ;)
>
>> Original github checks clean, but fail after manually bumping up the
>> version numbers in the branch. Unsure why.
>
> It conflicts with changes made to the master branch after you branched
> off (the version numbers, evidently).
>
>
> I must confess that version number handling is something that seriously
> bothers me, with a good solution still waiting to be found.
>
Attached is the same sequence of warps applied to a checker pattern on a
plane. No doubt I am interested in isosurfaces, but I also find it
easier to understand what a 3D pattern is really doing by creating
various shapes from the pattern.
As for version number handling I too am finding it awkward. I found
github wouldn't let me create a second fork for the base uberpov. I did
it the recommended way as another branch under my current fork. Because
the two git commit hook scripts are different I symbolically linked the
commit script into my repository, but the execute bits need to be
twiddled with on switching branches if I want it to run. Of course once
a branch has different version numbers these collide with the master
branch numbers on pull / merge. If you find - or figure out - a cleaner
method, please let us know.
Bill P.
Post a reply to this message
Attachments:
Download 'newblack_hole_type1aspat.jpg' (936 KB)
Preview of image 'newblack_hole_type1aspat.jpg'
![newblack_hole_type1aspat.jpg](/povray.beta-test/attachment/%3C57d400d6%40news.povray.org%3E/newblack_hole_type1aspat.jpg?ttop=441402&toff=150&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: New black_hole type of 1 proposed as github pull request #86.
Date: 11 Sep 2016 07:49:35
Message: <57d544cf$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 09/10/2016 06:45 AM, clipka wrote:
>
> It is quite obvious that your contributions are currently focused on
> isosurfaces; but since warps are pattern features, which are first and
> foremost texture tools, maybe an illustration of the new warps' effect
> on textures would also be of interest ;)
>
>
Woke up this morning wondering if due your request for an example
"texture" I should remark it looks like there is no normal support
within the warp code. I am ignorant of the history here and I am not
really sure of the implications...
Does the lack of warp.cpp nomral support mean if warp {} gets used in
say a texture map the normals within any given texture in the map won't
get transformed properly?
If so, or similar, should we document this?
I did another texture on a plane where I applied the old and new types
to a traditional wood pattern but used in the textures normal and not
the pigment. The pigment is Orange, the apparent grain is due the shadows.
Bill P.
Post a reply to this message
Attachments:
Download 'newblack_hole_type1asnrm.jpg' (501 KB)
Preview of image 'newblack_hole_type1asnrm.jpg'
![newblack_hole_type1asnrm.jpg](/povray.beta-test/attachment/%3C57d544cf%241%40news.povray.org%3E/newblack_hole_type1asnrm.jpg?ttop=441402&toff=150&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> wrote:
> Attached is the same sequence of warps applied to a checker pattern on a
> plane. No doubt I am interested in isosurfaces, but I also find it
> easier to understand what a 3D pattern is really doing by creating
> various shapes from the pattern.
This would make a great "rain" animation - and it would be interesting to use
_both_ the positive and negative black hole warps!
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: New black_hole type of 1 proposed as github pull request #86.
Date: 11 Sep 2016 09:27:41
Message: <57d55bcd$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 11.09.2016 um 13:49 schrieb William F Pokorny:
> Does the lack of warp.cpp nomral support mean if warp {} gets used in
> say a texture map the normals within any given texture in the map won't
> get transformed properly?
I must confess that I have no bloody freakin' idea :)
I do know that some things in normal handling are broken at a very
fundamental level, but when I turned my attention to trying to fix it
some years ago, I found that the topic can acommodate quite a lot of
brain-wrapping, took a step back, and haven't found the time yet to
tackle this issue again.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: New black_hole type of 1 proposed as github pull request #86.
Date: 30 Sep 2016 15:33:07
Message: <57eebdf3$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 10.09.2016 um 14:47 schrieb William F Pokorny:
>>> Original github checks clean, but fail after manually bumping up the
>>> version numbers in the branch. Unsure why.
>>
>> It conflicts with changes made to the master branch after you branched
>> off (the version numbers, evidently).
>>
>> I must confess that version number handling is something that seriously
>> bothers me, with a good solution still waiting to be found.
FYI, I've just ditched the running version number from the master
branch, as it turns out to really come crashing down with any reasonable
number of open pull requests around. Once you strip any trailing numbers
after the "alpha" from your pending pull requests, things should run a
good deal more smoothly from now on. (The pre-commit hook should be fine
with this new mode of operation, though it becomes less relevant anyway.)
I've instead added an advice to README.md to not build from the master
branch, but from tagged version only. Tagged versions will continue to
have trailing numbers after the "alpha" so that they can be uniquely
identified for the sake of providing support, but they will be managed
in a dedicated branch, to be updated from time to time from the master
branch.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: New black_hole type of 1 proposed as github pull request #86.
Date: 1 Oct 2016 05:59:24
Message: <57ef88fc$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 09/30/2016 03:33 PM, clipka wrote:
> Am 10.09.2016 um 14:47 schrieb William F Pokorny:
>
>>>> Original github checks clean, but fail after manually bumping up the
>>>> version numbers in the branch. Unsure why.
>>>
>>> It conflicts with changes made to the master branch after you branched
>>> off (the version numbers, evidently).
>>>
>>> I must confess that version number handling is something that seriously
>>> bothers me, with a good solution still waiting to be found.
>
> FYI, I've just ditched the running version number from the master
> branch, as it turns out to really come crashing down with any reasonable
> number of open pull requests around. Once you strip any trailing numbers
> after the "alpha" from your pending pull requests, things should run a
> good deal more smoothly from now on. (The pre-commit hook should be fine
> with this new mode of operation, though it becomes less relevant anyway.)
>
> I've instead added an advice to README.md to not build from the master
> branch, but from tagged version only. Tagged versions will continue to
> have trailing numbers after the "alpha" so that they can be uniquely
> identified for the sake of providing support, but they will be managed
> in a dedicated branch, to be updated from time to time from the master
> branch.
>
OK. Thanks. I'll update my remaining pull requests to this new approach.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |