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.

Post a reply to this message

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

Post a reply to this message

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 
using Google.


Mike

Post a reply to this message

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

Post a reply to this 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?

Post a reply to this message

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

Post a reply to this message

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)

Post a reply to this message

On 07/31/2018 04:39 AM, Le Forgeron wrote:
> Le 31/07/2018 à 04:32, dick balaska a écrit :
>> 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 
it helpful.

Post a reply to this message

Le 31/07/2018 à 15:20, William F Pokorny a écrit :
> On 07/31/2018 04:39 AM, Le Forgeron wrote:
>> Le 31/07/2018 à 04:32, dick balaska a écrit :
>>> 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
> it helpful.

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.

Post a reply to this message

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:
>>> Le 31/07/2018 à 04:32, dick balaska a écrit :
>>>> 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.

Post a reply to this message