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'

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

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'

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'

William F Pokorny <ano### [at] anonymousorg> 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

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

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

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