|
 |
"Robert McGregor" <rob### [at] mcgregorfineart com> wrote:
> I'm pretty happy with the ship model overall. I fine-tuned a few things on the
> engine assembly and started texturing the engines with some greebling, etc.
That is some really nice work, with lots of CGI details that 'look right' in
their shapes and positions. Very 'organic', like the old saying of "form follows
function." There are too many spaceships in movies that have way too much
oddly-placed clutter-- just to 'look' detailed. (I'm actually thinking of the
robots in the TRANSFORMERS movie franchise-- the robots keep evolving to be more
and more complicated, with doo-dads everywhere, to the point where I don't know
what I'm looking at!)
In your bottom row of images, I see some *great* surface texturing that you're
working on-- like random overlapping plates and such. I assume that it's done
with a single image_map (and accompanying normal_map?)-- wrapped around the
engine using a cylindrical warp, perhaps? In any case, it would be interesting
to know how you actually made the original image. It looks like a sophisticated
precedural tiling technique(?), perfect for spaceship surfaces and quite
beautiful.
> [Bald Eagle]
> ...The placement of all of those little pieces makes me wonder if it
> was done by eye and feel, or if there was some analytical geometry involved.
I usually use the built-in TRACE tool for placing such greebles on an object,
when they need to be in a regular pattern-- especially useful if the bigger
object is a symetrical shape like a cylinder or sphere. It has been awhile since
I used the technique (and I lost my original code), so I just came up with some
example code by going back to 'first principles'. There are probably some
built-in POV-ray functions in "transforms.inc" (or elsewhere) that would be less
complicated to use; but the following trig-based stuff seems to work well.
[Caveat: For a cone-like object such as Robert's engines-- with 'slanted
surfaces', unlike the surface on a straight cylinder-- there needs to be an
additional slight rotation of the greebles at some point, to slant them
appropriately to better-match the surface. I think that would probably have to
be done by eye-- unless there's some kind of simple formula for determining how
a cone's surface 'angle' deviates from a that of a straight cylinder.]
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.
------ [code] -----
#declare OBJ = // large main object
union{
cylinder{0, 2*x, .4}
sphere{0,.4 scale <3,1,1>}
pigment{srgb <.8,.5,.5>} // red
}
#declare GREEBLE =
union{
box{0,<1,6,1> translate <-.5,0,-.5> }
box{0,<6,1,1> translate <-.5,0,-.5> translate 6*y}
sphere{0,1.3 translate <6.5,6.5,0>}
scale .06
pigment{srgb <.5,1,.5>}
rotate 90*x // Yes, important. The traced surface locations below require
// this object to be oriented into +Z, not the usual +Y; due to the sin
// and cos values.
}
// from "math.inc', for the trig functions that use degrees instead of
// radians. I like to place these functions into the scene itself, instead of
// using #include "math.inc". More efficient!
#declare sind = function (x) {sin(radians(x))}
#declare cosd = function (x) {cos(radians(x))}
#declare NUM_OF_GREEBLES = 12;
#declare NORM = <0,0,0>; // to set this up for TRACE (a requirement)
union{
#for(A,1,NUM_OF_GREEBLES)
#local ANGLE = (A - 1)*360/(NUM_OF_GREEBLES);
#local SIND_RESULT = sind(ANGLE);
#local COSD_RESULT = cosd(ANGLE);
//#debug concat("\n","ANGLE = ",str(ANGLE,0,3))
//#debug concat("\n","SIN = ",str(sind(ANGLE),0,3))
//#debug concat("\n","COS = ",str(cosd(ANGLE),0,3),"\n\n")
#local TRACE_DISTANCE = 1.6;
#local FOUND_POS =
trace(
OBJ,<1.5,
TRACE_DISTANCE*SIND_RESULT, TRACE_DISTANCE*COSD_RESULT>,
<1.5,0,0> - <1.5, TRACE_DISTANCE*SIND_RESULT, TRACE_DISTANCE*COSD_RESULT>
NORM
);
#if(vlength(NORM) !=0)
object{GREEBLE
rotate (A - 1)*(-360/NUM_OF_GREEBLES)*x // NEGATIVE rotation to 'match'
// how the SIND and COSD values work
translate FOUND_POS
}
#else
#end
// TEMPORARY objects (thin white cylinders) to see the direction of the
// trace rays from the tracing locations...
cylinder{<1.5,0,0>,
<1.5, TRACE_DISTANCE*SIND_RESULT, TRACE_DISTANCE*COSD_RESULT>,.008
pigment {srgbt <1,1,1,.95>}
finish{ambient 0 emission 1 diffuse 0}
no_shadow
}
#end // of #for loop
object{OBJ}
translate <0,1.2,0> // everything
} // end of union
Post a reply to this message
Attachments:
Download 'greeble_placement_using_trace.png' (108 KB)
Preview of image 'greeble_placement_using_trace.png'
|
|
|
|
"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
|
|
