On 10/4/2010 12:30 PM, Christian Froeschlin wrote:
> Patrick Elliott wrote:
>
>> and on a plane placed on it, I could run tests runs, using the code,
>> to make sure that actually does what its supposed to. Problem is, I
>> only fiddle now and then with POVRay, so I have **no** clue how to
>> make a randomly created landscape, or use trace, or use trace from
>> "two" different objects (assuming that is even plausible), to get my
>> "this is where the ground is) value, and thus compute the rest of it...
>
> whoa. I think you need to take this one step at at time, your
> post contained a lot of detail without without quite pinpointing
> what you're trying to accomplish and your exact problem.
>
> I gathered you want to try some algorithm that traces some
> positions over random landscapes. You should probably forget
> about the details of your algorithm until you've set up a
> test environment.
>
> The easiest way to get a landscape is using a height_field.
> A height field can be based on a function instead of an image
> file, e.g.
>
> height_field
> {
> function 512, 512 {0.5+0.5*sin(10*x*y)}
> pigment {color White}
> }
>
> To get a random landscape, you will then need to get
> a random function. One way to do this is to use a noisy
> function such as f_bozo and vary the position where you
> evaluate it by some random parameters. Note this will
> not give a particularily pretty landscape. Look up "seed"
> and "rand" for getting some random numbers, but it will
> not be truly random and depend on your seed.
>
> Regarding trace: If your only intent is to get the height
> of the ground below some x,y coordinates, you can in this
> case of course simply stuff the coordinates into the function
> defining the height field as this already gives the height.
>
> More generally, the trace function takes one object (landscape),
> one point (position) and one vector (line direction) and will return
> the first point on the object which intersects the line (optionally,
> you can also get the normal vector of the surface).
>
> I hope this helps you get started.
>

Hmm. Ok. So.. lol

Well, I suppose I could constrain the area to test to a space within Y = 
0 -> 255, Y = 0 -> 255, for sake of getting results. The problem with 
trying to store the coordinates, instead of using something like trace, 
is the object I am placing "may" land some place better the grid points. 
Storing 65356 points is bad enough, without having to subdivide that by 
some fraction as well.

Like I said, I already have code I wrote to generate my points, I just 
can't "visualize" the result, or really test it visually in the 
environment I want to use it in.

The attached has an example, side view. Black is the landmass, blue the 
water level. The Yellowish box is an object that contains the script. 
The green circle is where the sphere is that defines the constraint for 
the appearance of objects. The pink ones are objects that are generated 
"inside" this region. In some cases I may need to generate a number of 
them all at "ground", but in most cases, the types can be floating over 
the ground as well. The salmon one is, more or less, an example of one 
that actually does physically appear in world. If you get within its 
radius, an object is created, and drops to the ground, which can be 
picked up.

The code I have already is written in Basic. Its going to be a bit 
more.. annoying, since the language I have to then parse this into 
doesn't support types. I.e., I have to use 4 "lists" (sort of an array), 
to handle each set of data for the objects, instead of just creating a 
type, which lets you split up the critical data. Mind, this may not be a 
big problem, since they do have a type that has <x,y,z,u> as attributes, 
so I could store the x,y,z, and a type, in that, as long as I remember 
its not a rotation, but rather coordinates and type data. lol

Basically though, the code is complete. Its just hard to visualize what 
the actual result is, without actual objects to look at. All I have, 
from the code, is a lot of numbers, which "look" like they are doing 
what I want. But I can't tune the design without being able to really 
see what I am ending up with.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Attachments:
Download 'example.png' (3 KB)

Preview of image 'example.png'

Patrick Elliott wrote:

> Well, I suppose I could constrain the area to test to a space within Y = 
> 0 -> 255, Y = 0 -> 255, for sake of getting results. The problem with 
> trying to store the coordinates, instead of using something like trace, 
> is the object I am placing "may" land some place better the grid points. 
> Storing 65356 points is bad enough, without having to subdivide that by 
> some fraction as well.

Of course, you can also use the trace function with a height_field
to take care of the correct interpolation between grid points. Just
use #declare POS = trace(TERRAIN,<px,100,pz>,-y)

> Like I said, I already have code I wrote to generate my points, I just 
> can't "visualize" the result, or really test it visually in the 
> environment I want to use it in.

If you already have coordinates, you can use them directly to
generate 3d objects in POV Ray, e.g., by writing an SDL include
file from your Basic program containing an array of coordinates
or a union of spheres.

What kind of sample data do you already have to test your
algorithm in Basic? Do you already have a 3d "terrain"? Or
do you wish to generate test data in POV-Ray?

Post a reply to this message

Any idea why Thunderbird sometimes completely screws up some messages? I 
had to go to the web view to see this at all, since the copy in 
Thunderbird was completely empty...

Worse.. Somehow, the "reply to" for this went to you, rather than the 
group... Resending it so it ends up there.. Very odd.. Wonder if it is 
some glitch with trying to read an email "while" its still downloading, 
or something.


 >> Well, I suppose I could constrain the area to test to a space within Y =
 >> 0 -> 255, Y = 0 -> 255, for sake of getting results. The problem with
 >> trying to store the coordinates, instead of using something like trace,
 >> is the object I am placing "may" land some place better the grid points.
 >> Storing 65356 points is bad enough, without having to subdivide that by
 >> some fraction as well.

 > Of course, you can also use the trace function with a height_field
 > to take care of the correct interpolation between grid points. Just
 > use #declare POS = trace(TERRAIN,<px,100,pz>,-y)

Hmm. Yeah, wasn't real sure how that worked, so was unclear how to 
manage it. I kind of hoped it would be the equivalent of what the 
world's own functions do, which is seems it would be. Those are llWater 
and llGround. Since I am going to be effectively substituting llWater 
for llGround, in cases where the later is lower than the former, one 
solution I thought about was to have a height field, then "clip" that, 
using a plane. For the purposes of visualizing the result, I don't need 
to know where one or the other is. That part is easy enough to work out, 
without testing. If the "base" comes up the same as the higher of the 
two, the code for it works. If not, then its not working. lol

 >> Like I said, I already have code I wrote to generate my points, I just
 >> can't "visualize" the result, or really test it visually in the
 >> environment I want to use it in.

 > If you already have coordinates, you can use them directly to
 > generate 3d objects in POV Ray, e.g., by writing an SDL include
 > file from your Basic program containing an array of coordinates
 > or a union of spheres.

 > What kind of sample data do you already have to test your
 > algorithm in Basic? Do you already have a 3d "terrain"? Or
 > do you wish to generate test data in POV-Ray?

Planned to generate the test data in POV-Ray. And, no I don't really 
have the coordinates *until runtime* either. The following is the test 
code I used to get the general concept working, mind, its messy, and I 
am adding some commentary to clear up what is happening, which the 
original doesn't have. But, initially, I just wanted to see if I could 
get "one" group to generate, within the parameters set for it. In the 
real situation I am actually going to be producing at least 3, perhaps 4 
such groups, with slightly different rules, for each one, depending on 
which type is involved.

// This declaration and the function are replaced with the inbuilt,
// llVecDist(<vector1>,<vector2>) function for the environment.
DECLARE FUNCTION vecdist! (x1!, x2!, y1!, y2!, z1!, z2!)

// Wish I could do this.. The language supported in the environment
// won't allow it, so I am going to have to either serialize the data,
// or use several arrays.
TYPE vects
   x AS SINGLE
   y AS SINGLE
   z AS SINGLE
   r AS SINGLE
   t as integer
END TYPE

DIM plist(6) AS vects

//For ease of identification. In POVRay this would be a color,
//while in the environment its intended for, it would be just
//a number, representing what effect getting too close has.
atyp$ = "FPRETO"

CLS
RANDOMIZE TIMER

//For simplisity sake, I use names that match the functions I will
//use here. For POVRay, these might be replaced with a plane + height
//field, and a call to the trace function, to get the height.
llground = 40
llwater = 37

//This is an arbitrary "height" for the scripts source object.
//All it does is define the max height something "can" be, based
//on the presumed "average" height of the landscape. I might decide
//to replace this with a set range of possible values, based on the
//radius of the "container" sphere.
posz = 120

//Determine where the "container" sphere is going to be, and how big.
//In world, this is the equivalent of 20-40 meters, within an area
//that *must not* allow a contained object to fall outside the 0-255
//coordinate limit in either direction.
rad = (RND(1) * 20) + 20
posx = RND(1) * (255 - ((rad + 1) * 2)) + rad
posy = RND(1) * (255 - ((rad + 1) * 2)) + rad

//This is all just to figure out where the "ground" actually is, i.e.,
//is it the ground level, or the water level?
gnd = llground
water = llwater
IF gnd < water THEN
   gnd = water
END IF

//Knowing which we will be using, we now determine what the
//range if heights this this is likely to occupy.
//For the test code, I assumed that "all" groups could be
//as much as 50 meters "over" the average land height.
//In cases where the ground was "below" this, the range becomes
//the difference between the real ground and the average + 50
//meters. It may be better, thinking on it, to either not use
//this, or only use it in cases it makes sense to (some types
//may reasonably do this, while others wouldn't).
//
IF gnd <= posz THEN
   bas = (posz - gnd) + 50
ELSE
   bas = 50
END IF
top = gnd + bas - rad
bottom = gnd + rad
PRINT
PRINT bas, rad
PRINT bottom, top
DO
   // Work out where our group actually is vertically, now that we have
   // the range it can show up in.
   //
   // Note: Types include >
   // 1. Fire - Probably ground only.
   // 2. Psi - Any range.
   // 3. Radiation - Probably ground only.
   // 4. Electrical - Any range.
   // 5. Poison - Any range.
   // 6. Tomoe (Hard to explain) - Probably ground only.
   // The "ground only" ones would replace "both" centerz, and the
   // z for each object as centerz = gnd, and posz = gnd,
   // respectively.
   //
   centerz = gnd + rad + RND(1) * (bas - (rad * 2))
   PRINT
   PRINT "center "; posx, posy, centerz
   count = 0
   tests = 0
   // Pick a type. Likely needs to be done "prior" to the centerz,
   // in the final version.
   mt = cint(rnd(1) * 6)

   // Now for the fun part.. We pick, at least, 7 points, possibly more,
   // if we end up overlapping any of the radii, and add them to our
   // list of coordinates.
   DO
     ncr = 1 + RND(1) * (rad / 5)
     DO
       ncx = posx + (RND(1) * (rad * 2)) - rad
       ncy = posy + (RND(1) * (rad * 2)) - rad
       ncz = centerz + (RND(1) * (rad * 2)) - rad

       // Assumes a flat plane. Since gnd is the same "everyplace"
       // in the test. In the POVRay version, and the real use for
       // the code, we need to check where the ground/water is here
       // too, since it may not be the same as for the container.
       if ncz < gnd then
         ncz = gnd
       end if

     // This is an example of the sloppy stuff here. I could do a lot
     // of complex math, using a rotation of A,B,C, and a radius
     // equal of lower than that of the container, but "may" waste
     // script time, it also may not work right in the final code.
     //
     // Why? Well, the final environment uses quarternions. So, I
     // either need some valid way to make a random one of those,
     // and I suspect that doing "<llFrand(1), llFrand(1), llFrand(1),
     // llFrand(1)> * (llFrand(1) * Radius)" won't cut it..
     // I am fairly certain that something like <1, .54435, .235, 1> is
     // **not** a valid quarternion, nor what the system would do with
     // such a number. OR I have to do "llEuler2Rot(<llFrand(TWOPI),
     // llFrand(TWOPI), llFrand(TWOPI)>) * llFrand(1) * Radius", and
     // hope that gimble lock doesn't frack up the whole process...
     //
     // I have yet to run tests to see if *either* will work. So,
     // checking to see if the position is "inside" based on distance
     // seemed the simplest option for testing.
     LOOP UNTIL vecdist(posx, ncx, posy, ncy, centerz, ncz) <= rad
     tests = tests + 1
     LOCATE 5, 1

     // Just to make things more interesting, its possible for "some"
     // of the types to end up different than the main one for the
     // whole set. Obviously, as per the prior list, the z coordinate
     // will need to be set to ground, or the selection ignored if that
     // is too far below, for some of them.
     if (rnd(1) < 0.012 then
       nt = cint(rnd(1) * 6)
     else
       nt = mt
     end if
     PRINT "newpos "; ncx, ncy, ncz, ncr
     PRINT "tests "; tests; " count "; count; "      "
     IF count = 0 THEN
       plist(count).x = ncx
       plist(count).y = ncy
       plist(count).z = ncz
       plist(count).r = ncr
       plist(count).t = nt
       count = count + 1
     ELSE
       FOR t = 0 TO count - 1
         IF vecdist(plist(count).x, ncx, plist(count).y, ncy, 
plist(count).z, ncz) > plist(count).r + ncr THEN
           plist(count).x = ncx
           plist(count).y = ncy
           plist(count).z = ncz
           plist(count).r = ncr
       plist(count).t = nt
           count = count + 1
           EXIT FOR
         END IF
       NEXT
     END IF
   LOOP UNTIL count = 7
   REM PRINT
   REM PRINT "dist "; vecdist(posx, ncx, posy, ncy, centerz, ncz)

   // Print my new list of positions.
   PRINT
   FOR t = 0 TO 6
     PRINT plist(t).x, plist(t).y, plist(t).z, plist(t).r, mid$(atyp$, 
plist(t).t, 1)
   NEXT
   DO
     ak$ = INKEY$
   LOOP UNTIL ak$ <> ""
LOOP UNTIL LCASE$(ak$) = "q"

FUNCTION vecdist (x1, x2, y1, y2, z1, z2)
   vecdist = SQR((x1 - x2) ^ 2 + (y1 - y2) ^ 2 + (z1 - z2) ^ 2)
END FUNCTION

Now, obviously, this only produces "one" set, not 3 or more. And, in the 
end, its all just a data generator, which needs to be tuned. Ultimately, 
once I know it is producing usable data, every time the system resets, 
it would produce a random number of these data sets, and someone 
entering the sim, while wearing a device that can talk to the script, 
will get a copy of the list. There will be three forms of this device:

1. Can spawn items, if you get close to one, and tracks things happening 
to you, if you wander through an area with one of these oddities in it.

2. Spawns items, and can warn you that you are getting close to something.

3. The final version uses "all" of the data, showing you what, where, 
etc. something is, based on how close you are, and which direction you 
are facing.

But, to finish that part of the project, I need something that can 
produce data, to feed it. And that is the point of trying it in POVRay 
first. ;)

Yeah. A real landscape would almost be nicer to work with, though I 
tried playing with a few things for making them, and.. they are damned 
annoying to get anything useful out of. But, they might be usable, as 
long as I can get a +- range of say.. 300 meters/units out of them, 
enough interesting variation to test this well. The "pit" in the example 
I attached, for example, is an interesting case, since it could 
constrain where in the sphere an object can even appear. The code I have 
above doesn't account for that at all, since it assumes a flat plane, 
and never checks if the height under an object is the same as under the 
center of its container. In the real implementation, this "has to" happen.


-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:

> Any idea why Thunderbird sometimes completely screws up some messages? I 
> had to go to the web view to see this at all, since the copy in 
> Thunderbird was completely empty...

I see it fine in Thunderbird.

> Planned to generate the test data in POV-Ray. And, no I don't really 
> have the coordinates *until runtime* either. The following is the test 
> code I used to get the general concept working

considering you already use vb as a test environment you
might try the following route to avoid reproducing everything
in SDL

1. Use POV-Ray to generate a grey scale heigth image
    (not rendering a height_field, just using texture
    to define terrain elevation). For testing purposes,
    you can skip this step and use handpainted data or
    terrain generated, e.g., from World machine.

2. Create a Bitmap object in your VB App. When determining
    the height of the ground over a position, use Bitmap.GetPixel
    to get the heigth information (rounding to the nearest pixel
    value may ok, otherwise, evaluate the four surrounding pixels
    and calculate the weighted average).

3. At the end of your algorithm, write an include file containing
    a union of spheres for the generated objects.

4. Render a POV-Ray scene containing a height_field based on
    the image and your exported spheres.

Post a reply to this message

On 7/10/2010 13:37, Patrick Elliott wrote:
> Any idea why Thunderbird sometimes completely screws up some messages? I 
> had to go to the web view to see this at all, since the copy in 
> Thunderbird was completely empty...

I see this all the time, it's a highly annoying bug in Thunderbird that
they don't seem to worry about fixing (I suspect because NNTP is fading out
of popularity). If Thunderbird is still downloading messages (even for
groups other than the one you are wanting to view), and you click on a new
message, it will show up blank. The only way to force it to load at that
point is to exit Thunderbird and re-start it.

> Worse.. Somehow, the "reply to" for this went to you, rather than the 
> group... Resending it so it ends up there.. Very odd.. Wonder if it is 

Yes, that's TB's default for newsgroups. Doesn't seem to make sense to me
either. I sometimes forget to do a followup to the NG and just hit reply -
my fix to prevent such emails from being sent (thus ensuring I notice) is
to set a custom (and invalid) SMTP server for the newsgroup account, rather
than allowing it to use the global default SMTP server. Thus when it
attempts to send the mail, it will fail.

-- Chris

Post a reply to this message

> On 7/10/2010 13:37, Patrick Elliott wrote:
>> Any idea why Thunderbird sometimes completely screws up some messages? I
>> had to go to the web view to see this at all, since the copy in
>> Thunderbird was completely empty...
>
> I see this all the time, it's a highly annoying bug in Thunderbird that
> they don't seem to worry about fixing (I suspect because NNTP is fading out
> of popularity). If Thunderbird is still downloading messages (even for
> groups other than the one you are wanting to view), and you click on a new
> message, it will show up blank. The only way to force it to load at that
> point is to exit Thunderbird and re-start it.
There is no interference with e-mail.
I don't see that problem, maybe because I only get the heathers from the 
news groups, and only download the messages as I read them.

>
>> Worse.. Somehow, the "reply to" for this went to you, rather than the
>> group... Resending it so it ends up there.. Very odd.. Wonder if it is
>
> Yes, that's TB's default for newsgroups. Doesn't seem to make sense to me
> either. I sometimes forget to do a followup to the NG and just hit reply -
> my fix to prevent such emails from being sent (thus ensuring I notice) is
> to set a custom (and invalid) SMTP server for the newsgroup account, rather
> than allowing it to use the global default SMTP server. Thus when it
> attempts to send the mail, it will fail.
>
> -- Chris

I always use TB and I never had any problem of replying to the sender 
instead of the group. Without any special configuration, my replys 
always goes to the group.


Alain

Post a reply to this message

On 10/7/2010 12:27 PM, Christian Froeschlin wrote:
> Patrick Elliott wrote:
>
>> Any idea why Thunderbird sometimes completely screws up some messages?
>> I had to go to the web view to see this at all, since the copy in
>> Thunderbird was completely empty...
>
> I see it fine in Thunderbird.
>
>> Planned to generate the test data in POV-Ray. And, no I don't really
>> have the coordinates *until runtime* either. The following is the test
>> code I used to get the general concept working
>
> considering you already use vb as a test environment you
> might try the following route to avoid reproducing everything
> in SDL
>
> 1. Use POV-Ray to generate a grey scale heigth image
> (not rendering a height_field, just using texture
> to define terrain elevation). For testing purposes,
> you can skip this step and use handpainted data or
> terrain generated, e.g., from World machine.
>
> 2. Create a Bitmap object in your VB App. When determining
> the height of the ground over a position, use Bitmap.GetPixel
> to get the heigth information (rounding to the nearest pixel
> value may ok, otherwise, evaluate the four surrounding pixels
> and calculate the weighted average).
>
> 3. At the end of your algorithm, write an include file containing
> a union of spheres for the generated objects.
>
> 4. Render a POV-Ray scene containing a height_field based on
> the image and your exported spheres.
Hmm. Interesting idea. Mind, I was using QBasic, but not hard to 
convert, and definitely easier to edit. lol Need to think about that 
possibility.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

On 10/7/2010 1:12 PM, Alain wrote:
> I always use TB and I never had any problem of replying to the sender
> instead of the group. Without any special configuration, my replys
> always goes to the group.
>
Its a symptom of the prior issue. I.e., if the message doesn't load 
correctly, it seems to have grabbed the name of the original sender, 
instead of the group. First time its happened to me. Usually I just skip 
messages which seem to have glitched, but this one was in my own thread, 
so.. lol


-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Chris Cason wrote:

> Yes, that's TB's default for newsgroups. Doesn't seem to make sense to me
> either. I sometimes forget to do a followup to the NG and just hit reply

I've never seen this ... if I reply to a post in the newsgroup it
will post it only to newsgroup. Only problem is I might accidentally
hit Reply All because its the required procedure at work for mail ;)
Currently using TB 2.0.0.24.

Post a reply to this message

Patrick Elliott <sel### [at] npgcablecom> wrote:
> I am fining myself in a position where I think I have some code that can
> be used, but I need to "see" it, but the place I plan to use it has
> restrictions, where I can't test it "in world". So, I figured I might be
> able to test it in POVRay, but to see if its working as espected, I need
> to test it against conditions like those its going to be running.
>

Some times ago, I wrote a endless pseudo random landscape scroller.
The code is this:

-------------------------------------------------------
global_settings {
   adc_bailout 0.00392157
   assumed_gamma 1.5
   noise_generator 2
}

background { rgb -.2}


/* sky_sphere {
   pigment {
      image_map {
         png
         "/bsys/Textures/Cosmos/Stars_Alphamap.png"
         map_type 0
      }
   }
}

*/
fog {
   fog_type 2
   distance 1.618
    rgb <0.66, 0.66, 0.66>
   fog_offset 0
   fog_alt 0.4
   up <0, 1, 0>
}

union {
   #declare Value=0.13;

   #declare fn_pattern=
     function {
       pattern { dents turbulence 0.9 scale 0.15
       translate y*5*clock
   }
   }

   height_field {
    function 800, 800 { fn_pattern(x, y, 0)*Value + 0.5 }
   }


   pigment {
      uv_mapping
      cells
      turbulence <1, 1, 1>
      omega 1
      lambda 6

      color_map {
         [ 0 color rgb <0.68627, 0.52157, 0.32157>   ]
         [ 0.95 color rgb <0.21176, 0.23922, 0.26275>   ]
         [ 0.98 color rgb <0.81569, 0.69412, 0.45098>   ]
         [ 1 color rgb <0.952941, 0.964706, 0.964706>   ]
      }
      matrix < 5, 0, 0,
               -1, 1, 0,
               0, 0, 1,
               0, 0, 0 >
   }

   normal {
      uv_mapping
      cells
      5
      turbulence <1, 1, 1>
      omega 1
      lambda 6
      matrix < 5, 0, 0,
               -1, 1, 0,
               0, 0, 1,
               0, 0, 0 >
      accuracy 0.01
   }
   scale <8, 6, 6>
   rotate <0, 0, 0>
   translate <-4, -2.9, -3>
}

light_source {
   <4, 5, -5>, rgb <0.9, 0.9, 0.9>
}

light_source {
   <-4, 5, -5>, rgb <0.3, 0.3, 0.3>
   shadowless
   media_interaction off
   media_attenuation off
}

camera {
   perspective
   location <0, 0.52, -3>
   sky <0, 1, 0>
   direction <0, 0, 1>
   right <1.6, 0, 0>
   up <0, 1, 0>
   look_at <0, 0.7, 50>
   angle 56
}
-----------------------------------------------------

It based on a heightfield with a "Dents"-pattern as a
function to the heightfield. IMO a very easy way, to
generate pseudo random landscapes.

Hope it helps.

Post a reply to this message