"Mr" <nomail@nomail> wrote:
> Blender addon does feature most POV-Ray primitives and its boolean modifier can
> be set to use POV-Ray CSG. If they happened to be out of odrer, I would be glad
> to at last have any form of feedback some day. :-)

Thanks Maurice, I will try it out!

Post a reply to this message

"Mr" <nomail@nomail> wrote:

> Wow ! will this be used in the alien artifact scene? I can't wait to see the
> update !

Yes, I'm almost finished with initial texturing and want to work it in somehow.

Post a reply to this message

Op 27/02/2021 om 11:19 schreef Kenneth:
[snip]
> Btw, I'm using trace's returned surface NORMAL only as a 'switch', to make sure
> that any *missed* traces don't result in greebles being placed at the <0,0,0>
> origin instead. The docs give an example of this. Otherwise, that normal isn't
> usually needed. Unfortunately, the only example of the trace command's use in
> the documentation concerns using that normal to actually *create* the
> greeble-like object. That's rather limiting; in most cases, it's easier and more
> logical to make such an object beforehand, IMO.
> 

I use trace pretty much like you; I don't remember where and if I got an 
example, but I am pretty sure you can use the surface normal generated 
by trace to positioning correctly the greebles an a slanted surface.

-- 
Thomas

Post a reply to this message

Op 27/02/2021 om 18:29 schreef Mr:
> "Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
>> Thomas de Groot <tho### [at] degrootorg> wrote:
>>> Good modelling! This is where a new version of Moray would be welcome...
>>
>> Thanks Thomas, and I agree, when building complex CSG models it sure would be
>> nice to be able to use a modeler that works with POV-Ray primitives.
> 
> Blender addon does feature most POV-Ray primitives and its boolean modifier can
> be set to use POV-Ray CSG. If they happened to be out of odrer, I would be glad
> to at last have any form of feedback some day. :-)
> 

I keep forgetting this because I (still) am not a Blender user myself... :-0

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 27/02/2021 om 11:19 schreef Kenneth:
> [snip]
> > Btw, I'm using trace's returned surface NORMAL only as a 'switch'...
>
> I use trace pretty much like you; I don't remember where and if I got an
> example, but I am pretty sure you can use the surface normal generated
> by trace to positioning correctly the greebles an a slanted surface.
>

It would seem so-- but there's possibly *some* kind of problem (maybe 'problem'
is not the right word) for how trace creates its normal in the first place. But
I haven't exactly narrowed the problem down to trace itself; it may be in how
the normal is being 'processed' by other POV-ray tools in order to make use of
it.

I've once again been experimenting with two macros in "transforms.inc" that can
take a vector (like trace's NORM) and re-orient it to another vector direction:
Point_At_Trans, and Reorient_Trans. The latter seems to be a better and more
mathematically sophisticated version of the former. But when trace's returned
NORM is derived from particular curved or slanted surfaces, both of those macros
start to produce major changes to the expected 'orientation' of a placed object.
It's an old effect (plainly seen on a sphere, where there are entire 'quadrants'
of objects that switch direction.) This effect *may* even be by design(!), out
of mathematical/logical necessity. But it gets in the way :-( The maths used in
those macros are somewhat over my head, although I've tinkered with them, with
no satisfactory result.

So I rarely use trace's NORM normal anymore; too many unexpected headaches when
trying to actually use it.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> It would seem so-- but there's possibly *some* kind of problem (maybe 'problem'
> is not the right word) for how trace creates its normal in the first place. But
> I haven't exactly narrowed the problem down to trace itself; it may be in how
> the normal is being 'processed' by other POV-ray tools in order to make use of
> it.

POV-Ray "measures" the normal of the surface that the ray intersects.
I'm pretty sure that there's no problem there.

Clearly understanding what those other macros actually do is probably where the
problem lies.

http://f-lohmueller.de/pov_tut/trans/trans_470e.htm

I must confess, things like this often become clear to me, and then I lose the
plot again a week later...

So if you have time and energy to do it, I'd copy those macros into scene files.
and then pick them apart, applying the parts step by step (if possible) and
understanding what the component operations actually do.

Pretend like you're explaining it to someone else, and document that in your
code.

A lot of what I've learned is due to digging into these really fundamental
things and writing scenes to illustrate them.  Because it confronts me with what
I don't know, and the consequences of my erroneous assumptions.

So I go from "I think I understand this"
to "I obviously have NO idea WTF I'm doing"
to "Well, that mostly works"
to "Oh - NOW I understand what's going on...."

And sometimes that may take me a day, a weekend, a week, a month, or in some
cases several years.

I'd look into vcross(), vdot(), and the order of rotations on a vector to move
it to properly align it with another vector.


https://www.youtube.com/watch?v=LyGKycYT2v0
https://www.youtube.com/watch?v=eu6i7WJeinw
https://www.youtube.com/watch?v=BaM7OCEm3G0
https://www.youtube.com/watch?v=Ip3X9LOh2dk

Not that I have _ever_ used quaternions before, but it does seem that they get
mentioned and used a lot, so maybe at some point I will muck around with those
for a bit.

https://www.youtube.com/watch?v=zjMuIxRvygQ

Post a reply to this message

Op 28/02/2021 om 14:54 schreef Kenneth:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Op 27/02/2021 om 11:19 schreef Kenneth:
>> [snip]
>>> Btw, I'm using trace's returned surface NORMAL only as a 'switch'...
>>
>> I use trace pretty much like you; I don't remember where and if I got an
>> example, but I am pretty sure you can use the surface normal generated
>> by trace to positioning correctly the greebles an a slanted surface.
>>
> 
> It would seem so-- but there's possibly *some* kind of problem (maybe 'problem'
> is not the right word) for how trace creates its normal in the first place. But
> I haven't exactly narrowed the problem down to trace itself; it may be in how
> the normal is being 'processed' by other POV-ray tools in order to make use of
> it.
> 
> I've once again been experimenting with two macros in "transforms.inc" that can
> take a vector (like trace's NORM) and re-orient it to another vector direction:
> Point_At_Trans, and Reorient_Trans. The latter seems to be a better and more
> mathematically sophisticated version of the former. But when trace's returned
> NORM is derived from particular curved or slanted surfaces, both of those macros
> start to produce major changes to the expected 'orientation' of a placed object.
> It's an old effect (plainly seen on a sphere, where there are entire 'quadrants'
> of objects that switch direction.) This effect *may* even be by design(!), out
> of mathematical/logical necessity. But it gets in the way :-( The maths used in
> those macros are somewhat over my head, although I've tinkered with them, with
> no satisfactory result.
> 
> So I rarely use trace's NORM normal anymore; too many unexpected headaches when
> trying to actually use it.
> 
> 
> 

Reorient_Trans, yes! That one I regularly use indeed. I must search my 
files where I apply it and whether I use the trace normal with it or not...

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ... but there's possibly *some* kind of problem (maybe 'problem'
> > is not the right word) for how trace creates its normal in the first
> > place. But I haven't exactly narrowed the problem down to trace itself;
> > it may be in how the normal is being 'processed' by other POV-ray tools..
> >
>
> POV-Ray "measures" the normal of the surface that the ray intersects.
> I'm pretty sure that there's no problem there.
>
> Clearly understanding what those other macros actually do is probably
> where the problem lies.
>

Yeah, I think you're right on both counts. For some strange reason, I've always
had a half-baked belief that trace's normal (or *any* normal) has a preferred
'handedness' when it comes to applying an object along that normal... meaning,
the normal ITSELF might somehow be *rotating* the object to a new orientation,
depending on which direction the normal faces into the x/y/z universe.  But
that's silly: a normal is *just a vector direction*. And I have to finally
dispel my mythical thinking. ;-) Thanks for waking up my tired ol' brain.

The object rotational problems I see when using the Point_At_Trans and
Reorient_Trans macros are specific to those tools, I agree. I've tried mightily
to 'correct' the resulting 'unexpected' object rotations (which DO result from
the normal's direction into space), but it's all quite mathematically
complicated.

Try tracing a simple sphere from random directions with thousands of greeble
objects applied, while using the found normals and those alignment macros to
place them, and you'll see what I mean.

Here's an example using the Point_At_Trans macro, applying typical pre-made
objects. Note the delineated 'diamond' rotational patches.

Post a reply to this message

Attachments:
Download 'traced_sphere_using_point_at_trans.jpg' (118 KB)

Preview of image 'traced_sphere_using_point_at_trans.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:

> The object rotational problems I see when using the Point_At_Trans and
> Reorient_Trans macros are specific to those tools, I agree. I've tried mightily
> to 'correct' the resulting 'unexpected' object rotations (which DO result from
> the normal's direction into space), but it's all quite mathematically
> complicated.

It's always complicated when we're using black-box macros and shooting in the
dark.

> Try tracing a simple sphere from random directions with thousands of greeble
> objects applied, while using the found normals and those alignment macros to
> place them, and you'll see what I mean.

Well, I tend to do things like that "by hand" using macros that I write deriving
everything from first-principles.

> Here's an example using the Point_At_Trans macro, applying typical pre-made
> objects. Note the delineated 'diamond' rotational patches.

They're not "diamonds" - they're triangles.

So let's peek into tranforms.inc:

// Similar to Reorient_Trans(), points y axis along Axis.
#macro Point_At_Trans (YAxis)
     // this is just a simple vector normalization.  No mystery.
     #local Y = vnormalize (YAxis);
     // this is a macro - I can't tell if it's a source-code thing, or a
math.inc thing. But here's where I think is what causes what you see. (* see
below)
     #local X = VPerp_To_Vector (Y);
     // vcross returns 0 when vectors are (anti-)parallel, and +/-1 when
perpendicular
     #local Z = vcross (X, Y);
     // As far as I can see, shear trans just applies a straightforward
transformation matrix, using x, y, and z.  And all those three vectors are
perpendicular, which is merely what all of the above code does.  And so the
whole object gets oriented to a "new y vector"
     Shear_Trans (X, Y, Z)
#end

* So, let's take a look at VPerp_To_Vector()
It takes a single argument.  Given a vector, find a vector perpendicular to it.
Which is ridiculous, given that I can spin a T-square around, and come up with
literally an infinite number of parallel vectors.

So let's take a look at what the macro specifically DOES.

Peeking into math.inc:

// Returns a vector perpendicular to V
// Author: Tor Olav Kristensen
#macro VPerp_To_Vector(v0)
   #if (vlength(v0) = 0)
      #local vN = <0, 0, 0>;
// Sanity check.   If you give it a/the zero vector, send it right back.

   #else
      #local Dm = min(abs(v0.x), abs(v0.y), abs(v0.z));

// And here's where we get the three-fold symmetry.  Find the smallest component
of the supplied vector.  This drives the rest of the macro results, which
computes the vector cross-product between your "new y vector" (the surface
normal), and the cardinal axis that it is "farthest away from".  What's the
center point of that 3-pronged choice tree?  The center of the triangle(s) in
your render.
Take a cardinal axis and start generating results from this macro as you rotate
it.  Eventually you will rotate it so far that a DIFFERENT cardinal axis will be
chosen by the macro to calculate the vector cross-product with.  And there are
only 3 axes, so you get triangular wedges of each octant of your sphere.

      #if (abs(v0.z) = Dm)
         #local vN = vnormalize(vcross(v0, z));
      #else
         #if (abs(v0.y) = Dm)
            #local vN = vnormalize(vcross(v0, y));
         #else
            #local vN = vnormalize(vcross(v0, x));
         #end
      #end
   #end
   vN // <--- returns one of three results
#end


So, now that we see where the problem is and why, we can formulate any number of
solutions.

The first and easiest is just write a new macro where you either use only one
dedicated axis as your second vector cross-product vector, or one where you can
choose which vector you want.  Or generate a random vector.

Second, you could take a look at which cardinal vector was used, and further
rotate your greeble based on that, to "correct" its orientation.

Maybe there are other options as well.

Maybe the POV-Ray light_source will shine its benevolent rays upon us, and TOK
will chime in with something elegant and brilliant.   :D

Post a reply to this message

So, following the logic from:
http://news.povray.org/povray.general/thread/%3Cweb.410eba6fcd20604ecbae57f30@news.povray.org%3E/?ttop=300207&toff=1950


just include transforms.inc, THEN redefine the "offending" macro:

#macro VPerp_To_Vector (v0)
 #if (vlength(v0) = 0)
  #local vN = <0, 0, 0>;
 #else
  #local x_point = vcross (x, v0);
  #if (vlength (x_point) = 0)
   #local x_point = vcross(y, v0); // if x was parallel to v0, try y instead
  #end
  #if (vlength (x_point) = 0)
   #local x_point = vcross(z, v0); // if x was parallel to v0, try y instead
  #end
 #end
  #local vN = x_point;
   vN
#end

Then generate your random points, find your intersection point and normal
vector,
#declare Normal = <0, 0, 0>;
#local iPoint = TracePointA (Sphere, Loc, Normal);
object {Greeble Point_At_Trans (Normal) translate iPoint}

and you should be good.

Post a reply to this message

Attachments:
Download 'greeble_placement.png' (196 KB)

Preview of image 'greeble_placement.png'