OK, I think I've gotten your vectors.inc merged into - and alongside - 
the core includes of my povr branch. With vectors.inc becoming one of 
the core include files.

Ended up... Sometimes wrapping macros in transforms.inc and math.inc to 
call your versions. Sometimes leaving the existing, roughly-equivalent 
macros but recommending your version in comments - and using yours over 
the old versions otherwise in the core include files.

As anticipated some minor changes in declared IDs due povr's lower case 
checking.

Added basic self testing of all the macros as a block appended to the 
bottom.

Turned out well. Thank you!

Only suggestion I'll make has to do with the documentation on your 
github page at: ttps://github.com/t-o-k/Useful-POV-Ray-macros.

With the VectorsFromTransform() and VectorsFromTransformFunction(), 
where you are showing the initialization of v_X, v_Y, v_Z and p_T, ahead 
of the macro calls; you could use the, new to v3.8, tuple initialization 
syntax. For example:

#declare (v_X,v_Y,v_Z,p_T) = (<0,0,0>,<0,0,0>,<0,0,0>,<0,0,0>);

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> OK, I think I've gotten your vectors.inc merged into - and alongside -
> the core includes of my povr branch. With vectors.inc becoming one of
> the core include files.

Good =)


> Ended up... Sometimes wrapping macros in transforms.inc and math.inc to
> call your versions. Sometimes leaving the existing, roughly-equivalent
> macros but recommending your version in comments - and using yours over
> the old versions otherwise in the core include files.

I'm a bit worried about the wrapping solution. That is because I'm contemplating
a minor change in either the OrthogonalVector() macro or the
AltOrthogonalVector() macro.

If one pass the same vector to both of these, I want the resulting vectors to
always be orthogonal to each other in addition to being orthogonal to the
vector passed to the macros.

Right now it is mostly so. But if if all the components in the passed vector are
equal, this will not be the case (except for the case were the passed vector is
the zero vector).

To fix this I would prefer to change the order of the "ifs" in the
OrthogonalVector() macro.

If the old VPerp_To_Vector() macro is changed to call (wrap) the new
OrthogonalVector() with reordered "ifs", it will break scenes using the
VPerp_To_Vector() macro.

So now I'm not sure what to do...


> As anticipated some minor changes in declared IDs due povr's lower case
> checking.
>
> Added basic self testing of all the macros as a block appended to the
> bottom.
>
> Turned out well. Thank you!

Thank you too !

I tried to look for your new core include files at your github pages, but I
could not find them there. Are they visible somewhere else ?


> Only suggestion I'll make has to do with the documentation on your
> github page at: ttps://github.com/t-o-k/Useful-POV-Ray-macros.
>
> With the VectorsFromTransform() and VectorsFromTransformFunction(),
> where you are showing the initialization of v_X, v_Y, v_Z and p_T, ahead
> of the macro calls; you could use the, new to v3.8, tuple initialization
> syntax. For example:
>
> #declare (v_X,v_Y,v_Z,p_T) = (<0,0,0>,<0,0,0>,<0,0,0>,<0,0,0>);

I had forgotten about this new initialization type. I've now changed the
examples to use it.

I've also changed the parameter names of the AccurateAngleBetweenVectors()
macro, so that are in line with the names in the other macros.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> To fix this I would prefer to change the order of the "ifs" in the
> OrthogonalVector() macro.
>
> If the old VPerp_To_Vector() macro is changed to call (wrap) the new
> OrthogonalVector() with reordered "ifs", it will break scenes using the
> VPerp_To_Vector() macro.
>
> So now I'm not sure what to do...

2 things here:

1.  I may be wrong, but I was under the impression that povr is a fork, and it's
purpose is to improve and fix some longstanding issues with the official povray
source code.  So breaking older scenes is probably not the primary concern.

2.  I thought that this was what the #version directive was for.  Can't you
sniff the scene version and include a fork in the wrapper?   If the version is
old, use the old way, and if it's new, use the new way?


-Bill

Post a reply to this message

On 5/28/21 6:53 PM, Tor Olav Kristensen wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> OK, I think I've gotten your vectors.inc merged into - and alongside -
>> the core includes of my povr branch. With vectors.inc becoming one of
>> the core include files.
> 
> Good =)
> 
> 
>> Ended up... Sometimes wrapping macros in transforms.inc and math.inc to
>> call your versions. Sometimes leaving the existing, roughly-equivalent
>> macros but recommending your version in comments - and using yours over
>> the old versions otherwise in the core include files.
> 
> I'm a bit worried about the wrapping solution. That is because I'm contemplating
> a minor change in either the OrthogonalVector() macro or the
> AltOrthogonalVector() macro.
> 
> If one pass the same vector to both of these, I want the resulting vectors to
> always be orthogonal to each other in addition to being orthogonal to the
> vector passed to the macros.
> 
> Right now it is mostly so. But if if all the components in the passed vector are
> equal, this will not be the case (except for the case were the passed vector is
> the zero vector).
> 
> To fix this I would prefer to change the order of the "ifs" in the
> OrthogonalVector() macro.
> 
> If the old VPerp_To_Vector() macro is changed to call (wrap) the new
> OrthogonalVector() with reordered "ifs", it will break scenes using the
> VPerp_To_Vector() macro.
> 
> So now I'm not sure what to do...

Change your code as you'd most like.

Indeed, I now have in math.inc:

// Returns a vector perpendicular to V
// Author: Tor Olav Kristensen
// See: OrthogonalVector() and AltOrthogonalVector() in vectors.inc
#macro VPerp_To_Vector(v0)
   //#error "VPerp_To_Vector in math.inc called. Use OrthogonalVector()"
     OrthogonalVector(v0)
#end

If need be, I can restore the old code. However, I think you are talking 
about differences 'only' with <1,1,1>, <-1,-1,-1> and the like - yes? 
And given I suspect folks might occasionally use OrthogonalVector() with 
AltOrthogonalVector(), maybe the OrthogonalVector() as the 
VPerp_To_Vector result is ultimately better too even changed.

What kind of trouble might we get into if we leave the wrap post your 
changes... My gut says nothing practically, but I guess the ultra safe 
approach would be to revert VPerp_To_Vector() - but then povr has three...

In any case, I think doing what's ultimately best in vectors.inc is the 
way to go for the future.

> 
...
> 
> I tried to look for your new core include files at your github pages, but I
> could not find them there. Are they visible somewhere else ?
> 

I've been releasing occasional tarballs in povray.binaries.programming, 
but none of this work is posted as yet.

I'm under code control locally, but I don't yet want to put what I have 
out there as code controlled until my code is closer to I have in mind 
for the final form. I plan to initialize it anew at some point. An 
issues we have with the current POV-Ray git repositories is they are 
carrying around a huge history for what the povr core code base is.

> 
>> Only suggestion I'll make has to do with the documentation on your
>> github page at: ttps://github.com/t-o-k/Useful-POV-Ray-macros.
>>
>> With the VectorsFromTransform() and VectorsFromTransformFunction(),
>> where you are showing the initialization of v_X, v_Y, v_Z and p_T, ahead
>> of the macro calls; you could use the, new to v3.8, tuple initialization
>> syntax. For example:
>>
>> #declare (v_X,v_Y,v_Z,p_T) = (<0,0,0>,<0,0,0>,<0,0,0>,<0,0,0>);
> 
> I had forgotten about this new initialization type. I've now changed the
> examples to use it.
> 
> I've also changed the parameter names of the AccurateAngleBetweenVectors()
> macro, so that are in line with the names in the other macros.

Cool.

Something I forgot to say explicitly is povr is v3.8 parsing + povr 
changes. That said, often, straight v3.8 stuff runs and once I had all 
the test cases in place, I did run the testing with a pure v3.8 compile 
and all was OK.

Ya know... I was thinking only v3.8 when mentioning the tuple feature 
new to v3.8. I think you were aiming for v3.7 and v3.8 with vectors.inc 
and, if so, might be worth a footnote where you've used the tuple syntax 
saying that it's a v3.8 feature. Or go back to the v3.7 example. Always 
the details...

Bill P.

Post a reply to this message

On 5/28/21 9:41 PM, Bald Eagle wrote:
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> 
>> To fix this I would prefer to change the order of the "ifs" in the
>> OrthogonalVector() macro.
>>
>> If the old VPerp_To_Vector() macro is changed to call (wrap) the new
>> OrthogonalVector() with reordered "ifs", it will break scenes using the
>> VPerp_To_Vector() macro.
>>
>> So now I'm not sure what to do...
> 
> 2 things here:
> 
> 1.  I may be wrong, but I was under the impression that povr is a fork, and it's
> purpose is to improve and fix some longstanding issues with the official povray
> source code.  So breaking older scenes is probably not the primary concern.

Yes, the povr branch breaks what it needs to break to fix longstanding 
issues - and to evolve more radically(1). It's a big part of the aim of 
of it.  So yep, the change likely doesn't matter even if it does break 
something...

(1) - So I can try more of what I want to try... :-)

> 
> 2.  I thought that this was what the #version directive was for.  Can't you
> sniff the scene version and include a fork in the wrapper?   If the version is
> old, use the old way, and if it's new, use the new way?

I suppose, but I'm trying to avoid as much of that sort of thing as 
possible with povr. I've been ripping out backward compatibility stuff 
as I can for a long time now and there is still lots of it in there...

Rambling. At a high level I think about the ever backward comparability 
in POV-Ray proper and it's kind of amazing it's been kept up. I mean it 
all more or less works! For what I'm doing it's just not possible in 
many cases - hammer in hand, I'm  breaking stuff.

Bill P.

Post a reply to this message