|
 |
"Bald Eagle" <cre### [at] netscape net> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > It seems to me that the pixel positions of a *u-v map* of a HF might
> > somehow be used to generate the trace-from points. Since the u-v map is
> > by nature a 'stretched-out' representation of the HF itself...
>
> The rectangle's x,z coordinates are the exact same thing as the u,v
> coordinates of the heightfield, in terms of the fact that you can't
> subdivide the u,v's any differently than the x,z's.
Yep, I get that.
I probably used the wrong nomenclature to describe what I mean. I meant to say,
"the pixel positions of the uv TEXTURE map (the generated image_map artwork
that's made in an app like UV Mapper.) In effect, a flat representation of the
'un-wrapped' HF. To initially get the trace-from positions-- not by initially
tracing the height_field itself (although that would also need to be done as a
2nd step, I think.)
Let's say that there are two triangles on the mesh HF that butt up against each
other. Assume that triangle #1 is almost flat horizontally, so it's a nice
little equilateral triangle. But triangle #2 turns out to have a very steep
slope on the HF, with its two base-points at almost 0.0 height, but its tip way
up at almost 1.0. So that triangle is extremely 'stretched', with more surface
area.
On the (flat) uv TEXTURE map or image_map, the 2nd triangle takes up lots more
space than triangle #1. Now assume that the final texture map has lots of these
different-sized triangluar areas.
That final image_map will have a 1X1 length-to-width ratio-- same as the
height_field square-- but obviously with some places that have NO representative
triangles on it; it's a visual representation of the un-folded HF, whatever odd
shape that turns out to be, 'pasted' onto a 1X1-ratio image size. But the lack
of triangles in some places is not really a problem for the scheme itself.
So my crazy idea is to randomly trace that TEXTURE map-- only for the 2-D
positions on it-- then to somehow correlate those found positions to the
'matching' triangles on the 3-D height_field, to finally place the greebles
during the subsequent (2nd) *HF*-tracing operation (using the typical top-down
tracing directions there, nothing fancy.) In my mind's eye, triangle
#1 will have a few 'hits', but triangle #2 will have *more* hits (because of its
larger surface area on the TEXTURE map)... in effect, making an 'even'
distribution of greeble placements on the HF itself.
Voila! Well, discounting the mathematical magic that would probably be required.
;-)
This is all conjecture, of course.
Post a reply to this message
|
|
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
I've done the VRand_ON_Box (RandSeed) awhile ago for my MeshTree project
along with VRand_ON_Cone,VRand_IN_Cone, VRand_ON_Cylinder, VRand_IN_Cylinder
I used them to place the end points of a binary tree.
When I looked back on them I found that the Cone marcos use a cone with a base
pov unit from <0,0,0,> the end point 1 unit in opposite direction 1 with the
base radius 1 and the other radius 0 and you had a choice of 3 directions to
place it
(x,y,z). The On_Cone also had the OPEN option.
The cylinder macro has the same basic lay out.
They work great for making trees but I don't know if they have an even
distribution.
Here they are copied from the modified rand.inc I use.
//a random point ON a square box {-1, 1}
#macro VRand_On_Box(R)// LR added
#local V=<0,0,0>;
#local a=int(rand(R)*6);
#switch (a)
#case(0)#local V=<-1,rand(R)*2-1,rand(R)*2-1>; #break
#case(1)#local V=<1,rand(R)*2-1,rand(R)*2-1>; #break
#case(2)#local V=<rand(R)*2-1,-1,rand(R)*2-1>; #break
#case(3)#local V=<rand(R)*2-1,1,rand(R)*2-1>; #break
#case(4)#local V=<rand(R)*2-1,rand(R)*2-1,-1>; #break
#case(5)#local V=<rand(R)*2-1,rand(R)*2-1,1>; #break
#end
(V)
#end
//a random point ON a Cylinder from -1 to 1 in the D direction
// radius=1
// if O open cylinder
// D=1 +y direction
// D=2 +x direction
// D=3 +z direction
#macro VRand_On_Cyl(D,O,R)// LR added
#local Theta = 2*pi*rand(R);
#local V=<0,0,0>;
#local H=rand(R)*2-1;
#local S=1; // radius
#if(O) #local Hv=1;
#else #local Hv=.95;
#end
#if (H>Hv) #local S=rand(R);#local H=1; #end
#if (H<-Hv) #local S=rand(R);#local H=0; #end
#if (D=1)#local V= <H,cos(Theta)*S,sin(Theta)*S>; #end
#if (D=2)#local V= <cos(Theta)*S,H,sin(Theta)*S>; #end
#if (D=3)#local V= <cos(Theta)*S,sin(Theta)*S,H>; #end
(V)
#end
//a random point IN a Cylinder from -1 to 1 in the D direction
// D=1 +y direction
// D=2 +x direction
// D=3 +z direction
#macro VRand_In_Cyl(D,R)// LR added
#local Theta = 2*pi*rand(R);
#local V=<0,0,0>;
#local H=rand(R)*2-1;
#local S=rand(R);
#if (D=1)#local V= <H,cos(Theta)*S,sin(Theta)*S>; #end
#if (D=2)#local V= <cos(Theta)*S,H,sin(Theta)*S>; #end
#if (D=3)#local V= <cos(Theta)*S,sin(Theta)*S,H>; #end
(V)
#end
//a random point ON a Cone from -1,1 to 1,0 in the D direction
// more values in the lower part
// if O open Cone
// D=1 +x direction
// D=2 +y direction
// D=3 +z direction
#macro VRand_On_Cone(D,O,RS)// LR added
#local Rt=rand(RS);
#local Rv=Rt*Rt;
#local Theta = 2*pi*rand(RS);
#local V=<0,0,0>;
#local H=Rv*2-1;
#local S=1-(H+1)/2;
#if(H<-.95 & O=0) #local S=rand(RS); #local H=-1;#end
#if (D=1)#local V= <H,cos(Theta)*S,sin(Theta)*S>; #end
#if (D=2)#local V= <cos(Theta)*S,H,sin(Theta)*S>; #end
#if (D=3)#local V= <cos(Theta)*S,sin(Theta)*S,H>; #end
(V)
#end
//a random point IN a Cone from -1,1 to 1,0 in the D direction
// more values in the lower part
// D=1 +y direction
// D=2 +x direction
// D=3 +z direction
#macro VRand_In_Cone(D,RS)// LR added
#local Rt=rand(RS);
#local Rv=Rt*Rt;
#local Theta = 2*pi*rand(RS);
#local V=<0,0,0>;
#local H=Rv*2-1;
#local S=1-(H+1)/2;
#local S=S*rand(RS);
#if (D=1)#local V= <H,cos(Theta)*S,sin(Theta)*S>; #end
#if (D=2)#local V= <cos(Theta)*S,H,sin(Theta)*S>; #end
#if (D=3)#local V= <cos(Theta)*S,sin(Theta)*S,H>; #end
(V)
#end
Post a reply to this message
|
|
