 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:web.6075d499a906d8e387570eabd4644d08@news.povray.org Robert
McGregor wrote:
> people might just find them annoying
Wellll everyting tha's better than I can do annoys me Grrrrr ;)
(A too distracted mind)
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "Mr" <nomail@nomail> wrote:
>> "Robert McGregor" <rob### [at] mcgregorfineart com> wrote:
>>> A detail render of the multiple beam towers doing whatever it is they do...
>>
>> they do it damn well !
>
> Thanks Maurice!
>
>
> Paolo Gibellini <p.g### [at] gmailcom> wrote:
>> The rocks are very... mmm... snowy? plastic?
>> I like them!
>
> Hahah, thanks Paolo - the rocks do look pretty terrible without textures, but
> that's part of the texturing fun for me - the illusion of detail :)
>
>
> Alain Martel <kua### [at] videotronca> wrote:
>> Now, add some focal blur to take the eye away from those rock formation.
>
> I thought about that at first, but today I've been playing around with tracing
> down some plants and I really like how it's looking now, so I'm probably going
> to leave everything in focus for this scene. Two plant species, three variations
> each, for a total of 30,000 plants traced down onto the rocks and ground plane.
> Attached is a detail of this setup.
>
>
>
>
That vegetation is quite convincing. Good work.
I've actually seen some real life rocks that had similar vegetation on them.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 13/04/2021 om 19:27 schreef Robert McGregor:
> ingo <ing### [at] tagpovrayorg> wrote:
>> I realy like your scenes and the "evolution images".
>
> Thanks Ingo, I wasn't sure if people might just find them annoying :)
>
>
"annoying" no; "instructive" yes.
We should all provide more scene building info like this.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Robert McGregor wrote on 12/04/2021 23:18:
> "Mr" <nomail@nomail> wrote:
>> "Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
>>> A detail render of the multiple beam towers doing whatever it is they do...
>>
>> they do it damn well !
>
> Thanks Maurice!
>
>
> Paolo Gibellini <p.g### [at] gmailcom> wrote:
>> The rocks are very... mmm... snowy? plastic?
>> I like them!
>
> Hahah, thanks Paolo - the rocks do look pretty terrible without textures, but
> that's part of the texturing fun for me - the illusion of detail :)
>
>
> Alain Martel <kua### [at] videotronca> wrote:
>> Now, add some focal blur to take the eye away from those rock formation.
>
> I thought about that at first, but today I've been playing around with tracing
> down some plants and I really like how it's looking now, so I'm probably going
> to leave everything in focus for this scene. Two plant species, three variations
> each, for a total of 30,000 plants traced down onto the rocks and ground plane.
> Attached is a detail of this setup.
>
>
>
>
The rocks now are truly impressive, one can imagine a whole ecosystem
between moss and grass!
Paolo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tagpovrayorg> wrote:
> in news:web.6075d499a906d8e387570eabd4644d08@news.povray.org Robert
> McGregor wrote:
>
> > people might just find them annoying
>
> Wellll everyting tha's better than I can do annoys me Grrrrr ;)
>
> (A too distracted mind)
Hahah!
Thomas de Groot <tho### [at] degrootorg> wrote:
> "annoying" no; "instructive" yes.
Thanks Thomas, that's good to know.
> We should all provide more scene building info like this.
Yes, _I_ would be certainly be interested in seeing how others go about building
their scenes.
Alain Martel <kua### [at] videotronca> wrote:
> That vegetation is quite convincing. Good work.
> I've actually seen some real life rocks that had similar vegetation on them.
Thanks very much Alain :)
Paolo Gibellini <p.g### [at] gmailcom> wrote:
> The rocks now are truly impressive, one can imagine a whole ecosystem
> between moss and grass!
Yes, the plants were a lot of fun for me, thanks Paolo.
Post a reply to this message
Attachments:
Download 'maidenvoyagewips-7-8.jpg' (958 KB)
Preview of image 'maidenvoyagewips-7-8.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 12/04/2021 om 23:39 schreef Robert McGregor:
> > "Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> > Hmm, I noticed that the previous image I posted doesn't show up in the Image
> > Digest - too large maybe?
> >
> > Here's a 1920x720px version...
> >
>
> I got it without a problem.
You use a newsreader so that works eh? It doesn't show up in the Web version of
the Image Digest that I use at http://news.povray.org, I guess the resolution is
too large.
> D*** good rocks and texturing! Look like some weathered granite outcrops
> with mossy overgrowing. A texture that leaves me slavering indeed ;-)
>
> With the vegetation the scene suddenly changes from inferred desert to
> savanna. I would like to see the view!
Thanks Thomas, here's a full sized render (which probably won't show up in the
web view).
Post a reply to this message
Attachments:
Download 'rwm_maidenvoyage_2560x1080px.jpg' (2002 KB)
Preview of image 'rwm_maidenvoyage_2560x1080px.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And here's a smaller version (width 1920px) of the "final" render since the
larger resolution again doesn't show up in the web-based Image Digest.
Post a reply to this message
Attachments:
Download 'rwm_maidenvoyage_1920x810px.jpg' (1163 KB)
Preview of image 'rwm_maidenvoyage_1920x810px.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "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
Hehe. I did not notice this post before long after you posted it...
You probably meant to write that there are an infinite number of vectors that
are orthogonal to a given vector.
I was a bit frustrated when somebody started to make a VPerp_To_Vector macro,
because how can one know which of these inifinite number of orthogonal vectors
the user needs or wants?
One can not know that. (More information is needed to calculate one specific
vector.)
But if the user doesn't care about anything else than that the returned vector
is orthogonal to the given vector, then a simple VPerp_To_Vector macro would be
feasible.
So I thought that if we were going to have such a macro, it should be a
numerical stable one. And my suggestion ended up as the VPerp_To_Vector macro in
math.inc. (Btw.: I don't like the name that it got.)
To be numerical stable, it should not try to calculate the cross product with a
vector that is parallel or almost parallel to the given vector. The simplest
candidate is the zero vector, which is orthogonal to all vectors. (The zero
vector can also be considered to be parallel to all vectors). But that would
certainly not be a useful candidate for the user. The second simplest candidate
for a vector to cross it with is the basis vector for the axis that is
"farthest" from it.
If you have a vector vA where the x component is the smallest, then the returned
vector is <0, -A.z, +A.y>.
If you have a vector vA where the y component is the smallest, then the returned
vector is <+A.z, 0, -A.x>.
If you have a vector vA where the z component is the smallest, then the returned
vector is <-A.y, +A.x, 0>.
For a vector to be orthogonal to another their dot product must be zero. I.e.:
<0, -A.z, +A.y> * <A.x, A.y, A.z> = 0
(0*A.x) + (-A.z*A.y) + (A.y*A.z) = 0
-A.y*A.z +A.y*A.z = 0
<+A.z, 0, -A.x> * <A.x, A.y, A.z> = 0
(+A.z*A.x) + (0*A.y) + (-A.x*A.z) = 0
+A.x*A.z -A.x*A.z = 0
<-A.y, +A.x, 0> * <A.x, A.y, A.z> = 0
(-A.y*A.x) + (A.x*A.y) + (0*A.z) = 0
-A.x*A.y +A.x*A.y = 0
Also note that in two dimensions there are only two 2 vectors that are
orthogonal to a given vector vA:
Those vecors are <+vA.v, -vA.u> and <-vA.v, +vA.u>.
Now notice the simlariy with the results from the VPerp_To_Vector macro.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
>...
> Also note that in two dimensions there are only two 2 vectors that are
> orthogonal to a given vector vA:
>
> Those vecors are <+vA.v, -vA.u> and <-vA.v, +vA.u>.
>...
Actually, no, that's not true. All scaled versions of these are also orthogonal
to vA.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> "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.
Hi Kenneth
You can try this:
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
#version 3.7;
#include "colors.inc"
global_settings { assumed_gamma 1.0 }
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
#macro OrientToNorth(vN, pL)
#local vC = vnormalize(vN);
#local vB = vnormalize(vcross(vC, y));
#local vA = vcross(vB, vC);
transform {
matrix <
vA.x, vA.y, vA.z,
vB.x, vB.y, vB.z,
vC.x, vC.y, vC.z,
pL.x, pL.y, pL.z
>
}
#end // macro OrientToNorth
#declare pCenter = <0, 3, 0>;
#declare Radius = 2;
#declare Sphere = sphere { pCenter, Radius }
union {
object { Sphere }
cylinder {
-(Radius + 1)*y, +(Radius + 1)*y, 0.05
translate pCenter
}
pigment { color White }
}
#declare Box = box { -<7, 2, 1>, +<7, 2, 1> }
#declare TraceDistance = 2*Radius;
#declare S1 = seed(27814);
#declare S2 = seed(12259);
#for (I, 1, 1000)
#declare vRandom = <1, 1, 1> - 2*<rand(S1), rand(S1), rand(S1)>;
#declare pTraceOrigin = pCenter + TraceDistance*vnormalize(vRandom);
#declare vTraceDirection = pCenter - pTraceOrigin;
#if (vTraceDirection.x != 0 & vTraceDirection.z != 0)
#declare vSurfaceNormal = <0, 0, 0>;
#declare pSurface =
trace(Sphere, pTraceOrigin, vTraceDirection, vSurfaceNormal);
#if (vlength(vSurfaceNormal) > 0)
object {
Box
scale <1, 1, 1>/100
pigment { color srgb <rand(S2), rand(S2), rand(S2)> }
OrientToNorth(vSurfaceNormal, pSurface)
}
#end // if
#end // if
#end // for
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
light_source {
100*<2, 5, 0>
color White
}
camera {
location <2, 3, 6>
look_at <0, 0, 0>
translate pCenter
}
// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
Note that this code will not attempt to place any objects exactly at the
"poles", since their desired orientation there is unknown.
Also see my recent reply to Bill in this thread.
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
Attachments:
Download 'orienttonorth.png' (101 KB)
Preview of image 'orienttonorth.png'
|
|
| |
| |
|
|
|
|
| |
|
|
