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