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