POV-Ray : Newsgroups : povray.advanced-users : Suggested / desired new ray / trace functions Server Time: 29 Sep 2020 11:41:57 GMT
 Suggested / desired new ray / trace functions (Message 1 to 10 of 10)
 From: Bald Eagle Subject: Suggested / desired new ray / trace functions Date: 20 Jul 2018 16:25:00 Message:
```After playing around for too long, and far too late with Mike's 3D offset
surface, I was thinking about how to expand on this and make it a broadly useful
tool.

Simply mapping the convex hull of a simple object would allow conversion to a
union of triangles, or a proper mesh{}, and "bumping it out" by a scalar
multiple of the normal vector would allow the generation of a (I find)
frequently desired nesting shape.

In order to model, meshify, and offset more complex objects, I was thinking that
an advanced version of trace() and perhaps a user-accessible version of the ray
intersection testing used for inside/outside or crossing tests could help define
such complex objects.

If the latter could return a scalar count, then the advanced trace () function
could return the position and normal of those crossing points, or just the
first, or second, or whichever one desired.
```
 From: Mike Horvath Subject: Re: Suggested / desired new ray / trace functions Date: 28 Jul 2018 07:34:10 Message: <5b5c1c72\$1@news.povray.org>
```On 7/20/2018 12:20 PM, Bald Eagle wrote:
> After playing around for too long, and far too late with Mike's 3D offset
> surface, I was thinking about how to expand on this and make it a broadly useful
> tool.
>
> Simply mapping the convex hull of a simple object would allow conversion to a
> union of triangles, or a proper mesh{}, and "bumping it out" by a scalar
> multiple of the normal vector would allow the generation of a (I find)
> frequently desired nesting shape.
>
> In order to model, meshify, and offset more complex objects, I was thinking that
> an advanced version of trace() and perhaps a user-accessible version of the ray
> intersection testing used for inside/outside or crossing tests could help define
> such complex objects.
>
> If the latter could return a scalar count, then the advanced trace () function
> could return the position and normal of those crossing points, or just the
> first, or second, or whichever one desired.
>
>
>
>
>

I remember someone tried to use trace() to generate a mesh from LGEO
parts, and ended up with a horrible mess of triangles.

Mike
```
 From: Mike Horvath Subject: Re: Suggested / desired new ray / trace functions Date: 30 Jul 2018 00:24:44 Message: <5b5e5acc\$1@news.povray.org>
```On 7/28/2018 3:34 AM, Mike Horvath wrote:
> I remember someone tried to use trace() to generate a mesh from LGEO
> parts, and ended up with a horrible mess of triangles.
>
>
> Mike

Maybe they used pov2mesh. I can't recall. I also can't find the render

Mike
```
 From: Le Forgeron Subject: Re: Suggested / desired new ray / trace functions Date: 30 Jul 2018 21:19:28 Message: <5b5f80e0\$1@news.povray.org>
```Le 20/07/2018 Ã  18:20, Bald Eagle a Ã©critÂ :
> After playing around for too long, and far too late with Mike's 3D offset
> surface, I was thinking about how to expand on this and make it a broadly useful
> tool.
>
> Simply mapping the convex hull of a simple object would allow conversion to a
> union of triangles, or a proper mesh{}, and "bumping it out" by a scalar
> multiple of the normal vector would allow the generation of a (I find)
> frequently desired nesting shape.
>

Looks like you would enjoy some mesh generation from
http://wiki.povray.org/content/User:Le_Forgeron/tesselation

Followed with some displace from
http://wiki.povray.org/content/User:Le_Forgeron/mesh

Or in the worst situation, data access (same page, at top) to the
initial mesh to create your own mesh in SDL.

> In order to model, meshify, and offset more complex objects, I was thinking that
> an advanced version of trace() and perhaps a user-accessible version of the ray
> intersection testing used for inside/outside or crossing tests could help define
> such complex objects.
>
> If the latter could return a scalar count, then the advanced trace () function
> could return the position and normal of those crossing points, or just the
> first, or second, or whichever one desired.
>
>
>
>
>
```
 From: Bald Eagle Subject: Re: Suggested / desired new ray / trace functions Date: 30 Jul 2018 23:50:00 Message:
```Le_Forgeron <jgr### [at] freefr> wrote:

> Looks like you would enjoy some mesh generation from
> http://wiki.povray.org/content/User:Le_Forgeron/tesselation
>
> Followed with some displace from
> http://wiki.povray.org/content/User:Le_Forgeron/mesh

Yes, that looks like a lot of things that would be very interesting to work
with.
:)

What are your recommendations for installing side-by-side with QtPOV-Ray?

is the a simple sudo apt-get install "...." that I can do?
```
 From: dick balaska Subject: Re: Suggested / desired new ray / trace functions Date: 31 Jul 2018 02:32:12 Message: <5b5fca2c\$1@news.povray.org>
```On 07/30/2018 07:46 PM, Bald Eagle wrote:

>
> What are your recommendations for installing side-by-side with QtPOV-Ray?
>

If'n I had stuck with my websockets edition (which I've abandoned now) I
could have easily added my websockets vfe to hgpovray and then the user
could select it as the render engine.

Now it would be possible to build qthgpovray as a separate program,
which may be easy. I touched nothing in ./source which is probably where
hgpovray did all of his work.   It would depend if he did something
funky to the Makefiles, like custom compile options.

--
dik
Rendered 328976 of 330000 (99%)
```
 From: Le Forgeron Subject: Re: Suggested / desired new ray / trace functions Date: 31 Jul 2018 08:39:48 Message: <5b602054\$1@news.povray.org>
```Le 31/07/2018 Ã  04:32, dick balaska a Ã©critÂ :
> On 07/30/2018 07:46 PM, Bald Eagle wrote:
>
>>
>> What are your recommendations for installing side-by-side with QtPOV-Ray?
>>
>
> If'n I had stuck with my websockets edition (which I've abandoned now) I
> could have easily added my websockets vfe to hgpovray and then the user
> could select it as the render engine.
>
> Now it would be possible to build qthgpovray as a separate program,
> which may be easy. I touched nothing in ./source which is probably where
> hgpovray did all of his work.   It would depend if he did something
> funky to the Makefiles, like custom compile options.
>

Nothing funky, and its all in my branch feature/extended-mesh, forked
fresh from official master branch

See if you want to pull it anywhere:

https://github.com/LeForgeron/povray/tree/feature/extended-mesh

The first commit is the patch,

The second commit is the merge into hgpovray38 (and you do not need it)
```
 From: William F Pokorny Subject: Re: Suggested / desired new ray / trace functions Date: 31 Jul 2018 13:20:09 Message: <5b606209\$1@news.povray.org>
```On 07/31/2018 04:39 AM, Le Forgeron wrote:
>> On 07/30/2018 07:46 PM, Bald Eagle wrote:
>>
....
>
>
> Nothing funky, and its all in my branch feature/extended-mesh, forked
> fresh from official master branch
>
> See if you want to pull it anywhere:
>
> https://github.com/LeForgeron/povray/tree/feature/extended-mesh
>
> The first commit is the patch,
>
> The second commit is the merge into hgpovray38 (and you do not need it)

I've not got your experience with code control, so perhaps asking a
stupid question.

Is there a reason you are not keeping your patches as independent
branches periodically re-based to master instead of merging them back
into hgpovray as posted on github?

I have my own 'povr' equivalent to 'hgpovray38' but I've been keeping
all my branches un-merged so as to both be able to periodically re-base
them to 'povray' master updates, but also so on merge I get only a
branch's specific changes.

This allows me - and anyone else - to pull github published fixes and
features into personal versions of povray. Usually with little or no
effort beyond doing the pull from github ahead of a build. If later, I
decide to exclude some feature, it's just a matter of not pulling it for
the next 'povr' build.

If I do the usual:

git pull https://github.com/LeForgeron/povray.git feature/extended-mesh

and that branch has been merged into hgpovray, I believe I'll get all of
the hgpovray updates at the point of the merge.

Probably, there is some way to pull the commit previous to the merge
specifically - if I know to do it. However, what happens six months or
two years from now when that branch's code has not been kept current to
povray's master, but rather kept current with some other version of
povray? I believe it becomes more and more difficult for others to make
routine use of such fix and feature branches.

I'm asking for mostly selfish reasons. There are often patches by you,
by Christoph with uberpov or others I want in my own routinely built
working version. I don't want to switch to uberpov or hgpovray to use
particular fixes and features. I want what I want all in my povr! This
is only easy if branches are kept apart from any larger build over time
and reasonably current to the povray master branch(1).

Bill P.

(1) - I understand that sometimes changes is such that keeping a branch
apart gets difficult or impossible. But where it can be done, thinking
```
 From: Le Forgeron Subject: Re: Suggested / desired new ray / trace functions Date: 31 Jul 2018 17:34:03 Message: <5b609d8b\$1@news.povray.org>
```Le 31/07/2018 Ã  15:20, William F Pokorny a Ã©critÂ :
> On 07/31/2018 04:39 AM, Le Forgeron wrote:
>>> On 07/30/2018 07:46 PM, Bald Eagle wrote:
>>>
> ....
>>
>>
>> Nothing funky, and its all in my branch feature/extended-mesh, forked
>> fresh from official master branch
>>
>> See if you want to pull it anywhere:
>>
>> https://github.com/LeForgeron/povray/tree/feature/extended-mesh
>>
>> The first commit is the patch,
>>
>> The second commit is the merge into hgpovray38 (and you do not need it)
>
> I've not got your experience with code control, so perhaps asking a
> stupid question.
>

Rule#1 : I suck at using git & github.

> Is there a reason you are not keeping your patches as independent
> branches periodically re-based to master instead of merging them back
> into hgpovray as posted on github?
>

I do not intend to waste time to rebase.

In previous 3.7, I tried to make a corrected master and a proper
hgpovray based on that master... additions were forked from hgpovray
before merging back into it. It failed when master started to get
refactored so heavily that it would need a complete rewrite of
everything in hgpovray.

This time, I have reduced my target: only one branch to keep alive,
hgpovray38.

I forked it from official master, and intend to pull from it again when
it moves (in a running state ! previously some commits in 3.7 get to a
non-working state, at least with some compilers).

Evolutions to integrate into hgpovray38 are forked from official master,
to ease, should it please power that be, an incorporation into official
code. (but I do not expect all of them to please, e.g. I have removed
the tiny rotation of text from hgpovray38, but it would be a long fight
I won't engage to ever get a removal of one line.)

Once done, I commit evolution on its own branch, push it on github and
yesterday havoc happened: I asked github a pull request to hgpovray and
it found a conflict, resolving the problem on website, it added a second
commit on the branch, then finished the pull on hgpovray38.

> I have my own 'povr' equivalent to 'hgpovray38' but I've been keeping
> all my branches un-merged so as to both be able to periodically re-base
> them to 'povray' master updates, but also so on merge I get only a
> branch's specific changes.
>
> This allows me - and anyone else - to pull github published fixes and
> features into personal versions of povray. Usually with little or no
> effort beyond doing the pull from github ahead of a build. If later, I
> decide to exclude some feature, it's just a matter of not pulling it for
> the next 'povr' build.
>

This assumes either preventive works, with no novelty, to check and
rebase every branches, without even warranting that the multiple
branches are compatible (or rather auto-mergeable), or that the
framework did not evolve so much as needing a total rewrite.

I have been proven wrong on the latter, and I have no interest for the
former.

Moreover, you have a "would-be-great-software-if-you-can-fusion"
solution, where I want a solution that I can use right now. The
difference between a modular vehicle you can change a lot of options,
but that you store as parts in your garage, and a ready to go vehicle in
my garage. Of course your garage is nice, but I'm too old for nice
modular everywhere, I just want a working vehicle without troubles
discovered during last minute assembly.

> If I do the usual:
>
> git pull https://github.com/LeForgeron/povray.git feature/extended-mesh
>
> and that branch has been merged into hgpovray, I believe I'll get all of
> the hgpovray updates at the point of the merge.

I have created a new branch feature/extended-mesh-proper to expose the
single commit of interest.

>
> Probably, there is some way to pull the commit previous to the merge
> specifically - if I know to do it. However, what happens six months or
> two years from now when that branch's code has not been kept current to
> povray's master, but rather kept current with some other version of
> povray? I believe it becomes more and more difficult for others to make
> routine use of such fix and feature branches.

If povray's master get updated, I will adapt in, and only in,
hgpovray38. Maybe an intermediate branch will appeared for the fix, but
it will only focus on the new commits from master and their impacts on
the result found in hgpovray38.

I do not aim at maintaining the intermediates branches.

>
> I'm asking for mostly selfish reasons. There are often patches by you,
> by Christoph with uberpov or others I want in my own routinely built
> working version. I don't want to switch to uberpov or hgpovray to use
> particular fixes and features. I want what I want all in my povr! This
> is only easy if branches are kept apart from any larger build over time
> and reasonably current to the povray master branch(1).

Good luck. I just want to keep hgpovray38 a bit ahead of master, tuned
to my desires and idea.

>
> Bill P.
>
> (1) - I understand that sometimes changes is such that keeping a branch
> apart gets difficult or impossible. But where it can be done, thinking

But I never got any feedback on my changes (fix or extensions) during
hgpovray (3.7), so I rather find maintaining them useless (call that
motivation ?).
Before git, patches of povray were often available as diff from official
release, git makes it easier, but I doubt older patches would have been
ported to new versions if new versions came out as fast as commits naw.

I guess everyone dreams of superpatch and megapatch, but that's a story
from another time. Megapatch was a great work, but it seems a hell to
integrate the various proposals.
```
 From: William F Pokorny Subject: Re: Suggested / desired new ray / trace functions Date: 1 Aug 2018 12:03:11 Message: <5b61a17f\$1@news.povray.org>
```On 07/31/2018 01:34 PM, Le_Forgeron wrote:
> Le 31/07/2018 Ã  15:20, William F Pokorny a Ã©critÂ :
>> On 07/31/2018 04:39 AM, Le Forgeron wrote:
>>>> On 07/30/2018 07:46 PM, Bald Eagle wrote:
>>>>
>
> Rule#1 : I suck at using git & github.
>

:-) I feel I do too, though I've gotten a little better over time. I
use Mercurial for my non-POV-Ray stuff, but there I'm not working
alongside others so it's easier overall.

>
>> Is there a reason you are not keeping your patches as independent
>> branches periodically re-based to master instead of merging them back
>> into hgpovray as posted on github?
>>
>
> I do not intend to waste time to rebase.

It does take time when there is change in the master which collides with
my branch changes otherwise not much. Suppose because I want to stay up
with master periodically doing the re-basing is easier than waiting a
long while and then trying to handling all colliding changes at once.

>
> In previous 3.7, I tried to make a corrected master and a proper
> hgpovray based on that master... additions were forked from hgpovray
> before merging back into it. It failed when master started to get
> refactored so heavily that it would need a complete rewrite of
> everything in hgpovray.
>

Understand. I'm with Christoph in his view gradual re-factoring is the
practical path to POV-Ray 4.0. Nothing to do in these situations except
do the work to recode to the refactoring. I've been bouncing back into
older versions often this year with the solver work. I like the
refactoring that got done - the code structure is cleaner.

A while back now Christoph encouraged me to create a pull request
against uberpov for one of my set of changes. Unfortunately, my changes
collided with re-factoring specific to uberpov. It was a lot of work to
get compiling and at the end of it I only ran a few sanity tests - not
the days and days of testing I'd done for my 'real' branch off POV-Ray
master.

The experience left me asking, how much value is something ported over
to uberpov in such a way... I don't run that tool day to day and just no
time to do duplicate the testing. I've certainly got no interest in
testing everything twice. Happens the branch and pull request never got
merged and I'm glad. Suppose people had tried it there but I'd screwed
up the port in a way my few sanity test didn't catch. Reality is most
folks on seeing a quick junk result will not give feedback - they'll
just think the code is junk! My C++ code sometimes is I suppose... :-)

The whole episode left me aiming to keep up with POV-Ray master and
nothing else.

> This time, I have reduced my target: only one branch to keep alive,
> hgpovray38.
>
> I forked it from official master, and intend to pull from it again when
> it moves (in a running state ! previously some commits in 3.7 get to a
> non-working state, at least with some compilers).
>
> Evolutions to integrate into hgpovray38 are forked from official master,
> to ease, should it please power that be, an incorporation into official
> code. (but I do not expect all of them to please, e.g. I have removed
> the tiny rotation of text from hgpovray38, but it would be a long fight
> I won't engage to ever get a removal of one line.)
>
> Once done, I commit evolution on its own branch, push it on github and
> yesterday havoc happened: I asked github a pull request to hgpovray and
> it found a conflict, resolving the problem on website, it added a second
> commit on the branch, then finished the pull on hgpovray38.
>

I just push to and pull from github. I do all my merging, re-basing and
so on locally. If I know merges might be messy or I'm not quite sure
what I'm doing I make sure I have a copy of my starting repository
directory somewhere - might be the one on github works. If things go
wrong, I delete the messed up directory in total, copy from the copy and
try again.

>
> This assumes either preventive works, with no novelty, to check and
> rebase every branches, without even warranting that the multiple
> branches are compatible (or rather auto-mergeable), or that the
> framework did not evolve so much as needing a total rewrite.
>

Agree. Sometimes I find myself with work to do to get back with the
master branch. I try not to have multiple personal branches that
overlap, but rather combine such overlaps in one stand alone branch
relative to master - so as not to create my own collisions.

>
> Moreover, you have a "would-be-great-software-if-you-can-fusion"
> solution, where I want a solution that I can use right now. The
> difference between a modular vehicle you can change a lot of options,
> but that you store as parts in your garage, and a ready to go vehicle in
> my garage. Of course your garage is nice, but I'm too old for nice
> modular everywhere, I just want a working vehicle without troubles
> discovered during last minute assembly.
>

Agree & understand.

>
>> If I do the usual:
>>
>> git pull https://github.com/LeForgeron/povray.git feature/extended-mesh
>>
>> and that branch has been merged into hgpovray, I believe I'll get all of
>> the hgpovray updates at the point of the merge.
>
> I have created a new branch feature/extended-mesh-proper to expose the
> single commit of interest.
>

I see it. An option for me would be to grab branches now and do the
re-basing myself over time - but then I've taken on that work and I'm
out of luck if you fix or improve something in the code at a later time.

>
>
> If povray's master get updated, I will adapt in, and only in,
> hgpovray38. Maybe an intermediate branch will appeared for the fix, but
> it will only focus on the new commits from master and their impacts on
> the result found in hgpovray38.
>
> I do not aim at maintaining the intermediates branches.
>

OK. Understand.

>
> Good luck. I just want to keep hgpovray38 a bit ahead of master, tuned
> to my desires and idea.
>

My aim for my own povr too.

>
> But I never got any feedback on my changes (fix or extensions) during
> hgpovray (3.7), so I rather find maintaining them useless (call that
> motivation ?).

I'd say I've given a little on the ovus and lemon, but generally agree.

Part of the problem is folks like me don't have much interest in jumping
to an otherwise back dated version of POV-Ray to use a feature or to
give feedback when any updates will be in a branch I'm not using daily.
If you keep hgpovray38 up with master this changes to the better - but I
still dislike jumping to a version which doesn't have my personal toys
inbuilt too.

I ported your lemon object from hgpovray (3.7) partly to learn about the
shape code, but as much because I wanted to make use of it in my
personal povr version. Creating the pull request to get it into POV-Ray
proper came later and mostly because I thought "why not" I now have the
lemon code branch in hand which will merge cleanly into the current
master.

> Before git, patches of povray were often available as diff from official
> release, git makes it easier, but I doubt older patches would have been
> ported to new versions if new versions came out as fast as commits naw.
>
> I guess everyone dreams of superpatch and megapatch, but that's a story
> from another time. Megapatch was a great work, but it seems a hell to
> integrate the various proposals.
>

Agree. Suppose no magic in the end and it's just hard no matter the
path. I appreciate the detailed response. Thanks.

Bill P.
```