 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
After playing with greeble placement on a sphere, I realized that there were no
macros in rand.inc for generating random points on the surface of things like
cubes, tori, cylinders and cones, etc.
I've written a few, and am picking away at the remaining ideas on my list, but
would like to assemble a reasonably complete collection before publishing for
overall critical review and testing. (contributions welcome)
As always, most everything is a rough draft that is a proof of concept, and
everything including the name is up for revision.
Some are just basic task macros that are used in the actual random distribution
macros.
What I have so far is:
MakePerpendicularVector (v0) - basically just the alternate version of
VPerp_To_Vector (v0) with a different name to differentiate it.
Rand_Integer (Min, Max, RandSeed)
// Returns an integer from Min to Max, inclusive [Min ... Max]
Array_Of_Integers (Min, Max)
// Creates an array of integers from Min to Max inclusive [Min ... Max]
Rand_Element_In_Array (Array, Dim, RandSeed)
// Returns a random element of a dimension of an array
VRand_In_Rectangle (V_Plane, S_Width, S_Height, S_RandSeed)
// Returns a random point in a rectangle lying in the specified plane
VRand_ON_Box (RandSeed)
// Returns a random point on an origin-centered unit box
VRand_ON_Circle (RandSeed)
// Returns a random point on an origin-centered unit circle (radius = 1)
VRand_ON_Cone (Height, radA, radB, RandSeed)
// Returns a random point on a cone (or cylinder)
VRand_In_Cone (Height, radA, radB, RandSeed)
// Returns a random point IN a cone (or cylinder)
VRand_ON_Parametric (UVstart, UVend, fnX, fnY, fnZ, RandSeed)
// Returns a random point on a parametric surface
This will probably be general purpose, with calls to it for generating
points on a torus, etc
I'm using the #if (input_file_name = "RandomDistributions.inc") trick to set up
a test scene (no #camera - only using the default), and every macro will have a
companion test macro to demonstrate that it works, and provide a working syntax
and code/usage example.
So VRand_ON_Parametric (UVstart, UVend, fnX, fnY, fnZ, RandSeed) will have a
VRand_ON_Parametric_TEST () macro to go along with it.
Remaining ideas slated for development are:
VRand_ON_SOR ()
VRand_ON_Lathe ()
VRand_ON_Prism ()
VRand_In_Polygon () Not sure "vrand in object" will work - will inside() tests
work with planar objects?
VRand_ON_BicubicPatch ()
VRand_ON_Isosurface ()
Folks are welcome to beat me to the punch, or write their own versions to
compare approaches, efficiency, flexibility, speed, etc.
Other areas of future interest:
Prism <x,z> syntax infuriates me, and so I'd like to write a tidy macro to use
<x,y,z> coordinates, probably from an array, and maybe another macro to take the
<x,z> part of a prism and create an array of proper <x, y, z> coordinates.
Is it somehow possible (in SDL) to divine how many arguments an extant function
requires? That would be useful. We have dimension_size for arrays...
clipka noted the shortcomings of HSV, and I was wondering if some of the people
who play with color spaces and interpolation might come up with something along
the lines of: https://www.alanzucconi.com/2017/07/15/improving-the-rainbow-2/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 02/03/2021 om 23:30 schreef Bald Eagle:
> After playing with greeble placement on a sphere, I realized that there were no
> macros in rand.inc for generating random points on the surface of things like
> cubes, tori, cylinders and cones, etc.
>
>
> I've written a few, and am picking away at the remaining ideas on my list, but
> would like to assemble a reasonably complete collection before publishing for
> overall critical review and testing. (contributions welcome)
>
> As always, most everything is a rough draft that is a proof of concept, and
> everything including the name is up for revision.
> Some are just basic task macros that are used in the actual random distribution
> macros.
>
> What I have so far is:
>
> MakePerpendicularVector (v0) - basically just the alternate version of
> VPerp_To_Vector (v0) with a different name to differentiate it.
>
> Rand_Integer (Min, Max, RandSeed)
> // Returns an integer from Min to Max, inclusive [Min ... Max]
>
> Array_Of_Integers (Min, Max)
> // Creates an array of integers from Min to Max inclusive [Min ... Max]
>
> Rand_Element_In_Array (Array, Dim, RandSeed)
> // Returns a random element of a dimension of an array
>
> VRand_In_Rectangle (V_Plane, S_Width, S_Height, S_RandSeed)
> // Returns a random point in a rectangle lying in the specified plane
>
> VRand_ON_Box (RandSeed)
> // Returns a random point on an origin-centered unit box
>
> VRand_ON_Circle (RandSeed)
> // Returns a random point on an origin-centered unit circle (radius = 1)
>
> VRand_ON_Cone (Height, radA, radB, RandSeed)
> // Returns a random point on a cone (or cylinder)
>
> VRand_In_Cone (Height, radA, radB, RandSeed)
> // Returns a random point IN a cone (or cylinder)
>
> VRand_ON_Parametric (UVstart, UVend, fnX, fnY, fnZ, RandSeed)
> // Returns a random point on a parametric surface
> This will probably be general purpose, with calls to it for generating
> points on a torus, etc
>
>
> I'm using the #if (input_file_name = "RandomDistributions.inc") trick to set up
> a test scene (no #camera - only using the default), and every macro will have a
> companion test macro to demonstrate that it works, and provide a working syntax
> and code/usage example.
> So VRand_ON_Parametric (UVstart, UVend, fnX, fnY, fnZ, RandSeed) will have a
> VRand_ON_Parametric_TEST () macro to go along with it.
>
> Remaining ideas slated for development are:
> VRand_ON_SOR ()
> VRand_ON_Lathe ()
> VRand_ON_Prism ()
> VRand_In_Polygon () Not sure "vrand in object" will work - will inside() tests
> work with planar objects?
> VRand_ON_BicubicPatch ()
> VRand_ON_Isosurface ()
>
> Folks are welcome to beat me to the punch, or write their own versions to
> compare approaches, efficiency, flexibility, speed, etc.
>
> Other areas of future interest:
>
> Prism <x,z> syntax infuriates me, and so I'd like to write a tidy macro to use
> <x,y,z> coordinates, probably from an array, and maybe another macro to take the
> <x,z> part of a prism and create an array of proper <x, y, z> coordinates.
>
> Is it somehow possible (in SDL) to divine how many arguments an extant function
> requires? That would be useful. We have dimension_size for arrays...
>
> clipka noted the shortcomings of HSV, and I was wondering if some of the people
> who play with color spaces and interpolation might come up with something along
> the lines of: https://www.alanzucconi.com/2017/07/15/improving-the-rainbow-2/
>
I am quite a heavy user of VRand_In_Obj() myself, and except for
VRand_On_Sphere there are no other "ON" (flat) distributions available
where objects are concerned. I wonder if your list of "ON" objects
cannot be reduced by one single VRand_On_Obj() macro? At least where 3d
objects are concerned? 2d objects are another kettle of fish I presume
and it is certainly not out of iddleness that you mention them separately.
I have used trace() combined with a VRand_ to put things'on' a given
object, of whatever form, but your solution(s) would be more interesting
indeed.
Usefull are also any gaussian distributions 'in' or 'out' of a surface
or object. I have a couple of examples I need to dig up....(added here)
maybe you can use them...
--
Thomas
Post a reply to this message
Attachments:
Download 'distributiont scenes.zip' (1283 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> I am quite a heavy user of VRand_In_Obj() myself, and except for
> VRand_On_Sphere there are no other "ON" (flat) distributions available
> where objects are concerned. I wonder if your list of "ON" objects
> cannot be reduced by one single VRand_On_Obj() macro? At least where 3d
> objects are concerned?
Well, unless you have some insight into _how_ to accomplish that, where I will
once again go "oh - duh. I should have seen that," then I think it's a bit
more complicated than that.
How do you "get to" the inside hole of a torus with such a method?
2 holes? 3? 42?
What if I have a bowl that I want to cover the _inside_ of with random points?
I think it goes back to all of the experiments where people have tried to
"meshify" objects using trace(). It's damned tricky.
But having pointed that out, maybe LeForgeron has some ideas about how to go
about it.
And then, as I discovered, after hunting down a curious line of code in Ingo's
vrand on sphere macro, that there's the matter of not just randomly placed - but
EVENLY placed. The distributions can be quite tricky.
Lets say we take a landscape heightfield and try to place objects onto it. If
we just trace() straight down from an imaginary rectangle of ray starting
coordinates, then the regions of rapidly changing elevation don't get as much
arc-length coverage as the flat parts.
> 2d objects are another kettle of fish I presume
> and it is certainly not out of iddleness that you mention them separately.
Yes, because there is no inside() to those things.
> I have used trace() combined with a VRand_ to put things'on' a given
> object, of whatever form, but your solution(s) would be more interesting
> indeed.
The problem that I see there is that you have to home-brew a coverage algorithm
to generate the start and direction vectors for trace to use, and probably have
a fair number of rejected hit-or-miss test rays.
For specific well-defined surfaces, it seemed better to have all of the random
points picked already be 100% valid.
> Usefull are also any gaussian distributions 'in' or 'out' of a surface
> or object. I have a couple of examples I need to dig up....(added here)
> maybe you can use them...
I'll give them a look - thanks :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just gonna think out loud here, so that people can follow the thought process
(or lack thereof), and see some of the challenges, limitations, problems,
complexities, hidden difficulties, and perhaps offer some more experienced
insights and solutions for addressing the issues.
I'm working on writing VRand_In_Polygon.
I can't just plug in a polygon object as an argument, because in order to
calculate the winding number to see if the point is inside the polygon, I need
access to the array of points that make up the polygon. And the user doesn't
have access to that data through SDL.
(I wonder if there's a sort of data-structure "union" that could be implemented,
such that "internal" data of an object could be accessed. Polygon.array or
something like that.)
So, for testing, I define an array, define a polygon constructed from that
array, and then pass the array on to the VRand_In_Polygon macro.
VRand_In_Polygon now has to do a few interesting things.
First, because I have an array and not an object, I can't use min_extent and
max_extent - I have to initialize min and max with the first element of the
array, and then cycle through the rest of the array, updating the min and max
vertex components. Using that as my bounding rectangle, I generate a random
point in that rectangle, and pass the test point and the vertex array on to the
WindingNumber macro.
WindingNumber as written, returns 0 for outside, 1 for inside.
return (cn&1); // 0 if even (out), and 1 if odd (in)
Not sure what the & notation is - maybe xor or something....
But then it occurred to me that, as a class, many of these
generate-a-random-point macros have 2 glaring problems.
The first, is that a lot of the same data gets repeatedly generated inside the
macro as a result of the macro being called from an external loop. So if I want
to plot 1000 points inside of a polygon, I have to do ALL of that stuff every
time the macro is called. Wasteful and foolish.
The second, is that most of these hit-or-miss macros only return a point that
has passed the "inside" or "on" test. Which is great - but what if a user wants
to plot ALL of the randomly generated points and do something like color the
inside/on points green and the outside/off points red? Can't do that.
So I'm considering 2 things:
1. Rewrite the macros to accept a number-of-iterations argument, and do all of
the point generation and testing _inside of the macro_ after all of the setup
calculations are done _once_, and then return not a point, but an _array_ of
results.
2. rewriting / supplementing those macros with a version that returns a
4-component vector: <x, y, z, flag>.
That way the output of the test function returns all of the available
information for the user to work with. Be it plot a point, not plot a point,
count the pass/fail for a graph or histogram / statistical report, etc.
Maybe the testing is done for object placement on terrain, and "inside" is a
lake, and "outside" is land. Or for an animation, where rain drops are falling,
or the object tests are used to determine if a rubber ball hits a hard or
soft/sticky surface......
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> return (cn&1); // 0 if even (out), and 1 if odd (in)
> Not sure what the & notation is - maybe xor or something....
logical and. as per comment, the LSB (least significant bit) of 'cn' is
returned.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 03/03/2021 om 13:00 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>
>> I am quite a heavy user of VRand_In_Obj() myself, and except for
>> VRand_On_Sphere there are no other "ON" (flat) distributions available
>> where objects are concerned. I wonder if your list of "ON" objects
>> cannot be reduced by one single VRand_On_Obj() macro? At least where 3d
>> objects are concerned?
>
> Well, unless you have some insight into _how_ to accomplish that, where I will
> once again go "oh - duh. I should have seen that," then I think it's a bit
> more complicated than that.
>
> How do you "get to" the inside hole of a torus with such a method?
> 2 holes? 3? 42?
> What if I have a bowl that I want to cover the _inside_ of with random points?
Ouch! That hurts! :-) You are absolutely right of course and I didn't
think the problem through obviously.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> And then, as I discovered, after hunting down a curious line of code in Ingo's
> vrand on sphere macro, that there's the matter of not just randomly
> placed - but EVENLY placed. The distributions can be quite tricky.
>
> Lets say we take a landscape heightfield and try to place objects onto
> it. If we just trace() straight down from an imaginary rectangle of
> ray starting coordinates, then the regions of rapidly changing elevation
> don't get as much arc-length coverage as the flat parts.
>
Yeah, that little problem has always been a thorny one to try and solve. But I
just had a wild idea (possibly a naive one):
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-- covering all of the HF's area,
and with more points or pixel positions than a typical
'trace-down-from-rectangular-area' scheme -- the uv-map's points or pixels could
then be correlated (somehow) with the corresponding points on the HF... the
result being to 'evenly' cover the HF with trace rays, even on steep elevations.
That's what I see in my minds eye, anyway.
In "shapes.inc", there are macros for creating mesh HFs in various shapes-- I'm
thinking of HF_Square() there, which then uses HF_Create() to produces u-v
coordinates, I think. (It has been awhile since I've used them.) Maybe the code
there would give a clue as to how this scheme could be implemented, in concert
with trace.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > And then, as I discovered, after hunting down a curious line of code in Ingo's
> > vrand on sphere macro, that there's the matter of not just randomly
> > placed - but EVENLY placed. The distributions can be quite tricky.
> >
> > Lets say we take a landscape heightfield and try to place objects onto
> > it. If we just trace() straight down from an imaginary rectangle of
> > ray starting coordinates, then the regions of rapidly changing elevation
> > don't get as much arc-length coverage as the flat parts.
> >
>
> Yeah, that little problem has always been a thorny one to try and solve. But I
> just had a wild idea (possibly a naive one):
> 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-- covering all of the HF's area,
> and with more points or pixel positions than a typical
> 'trace-down-from-rectangular-area' scheme -- the uv-map's points or pixels could
> then be correlated (somehow) with the corresponding points on the HF... the
> result being to 'evenly' cover the HF with trace rays, even on steep elevations.
> That's what I see in my minds eye, anyway.
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. Aside from scale and absolute location, they're
exactly the same.
What needs to be done is to calculate the arc length of the curve in the u or v
direction, and then compensate for that additional distance by clustering more
random samples in those areas.
https://www.mathwords.com/a/arc_length_of_a_curve.htm
This seems to be closely related to the "importance sampling" clipka was looking
for.... 5 years ago. :O
http://news.povray.org/povray.advanced-users/thread/%3C57bf8a2f%241%40news.povray.org%3E/?ttop=433049&toff=150&mtop=410
480
It's NOT trivial, but if it were simply a matter of investing the time to
one-time algorithmically process the hf for a scene and save the data to a file,
then it probably would be worth doing...
http://news.povray.org/web.60330f52d0c3b58b1f9dae300%40news.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> What needs to be done is to calculate the arc length of the curve in the u or v
> direction, and then compensate for that additional distance by clustering more
> random samples in those areas.
So, this just popped into my head, inspired by your comment and my thinking
about Vrand_on_Bezier -
There are the clock / spline macros that plot points uniformly over a spline.
Scan in the data across the u direction, saving to a spline / array, and
increment down the hf in the v direction.
Then rather than plot the point on the hf directly, plot it on the spline.
If those macros work for bezier splines, then that may be a solution for Cousin
Ricky's scene as well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 04/03/2021 à 20:22, Bald Eagle a écrit :
> What needs to be done is to calculate the arc length of the curve in the u or v
> direction, and then compensate for that additional distance by clustering more
> random samples in those areas.
>
> https://www.mathwords.com/a/arc_length_of_a_curve.htm
>
When someone says that every length can be computed, I am reminded of
the ellipse.
You can compute the area of the ellipse accurately, but not its perimeter.
And if you have a formula for the length of the perimeter of the
ellipse, a true formula, not an approximation, you are an alien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
