 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'd like to place some objects semi-randomly in a scene.
Semi, because they should not intersect or overlap other stationary objects.
It seems to me that this ought to be a classic issue in video games, and one
that's been long solved, and I will research it further.
I do however have limited time, and if someone can nudge me over to a quick
resolution of the problem, that would be great.
Basically I want to take some short strings and have them fade in and out of the
"open areas" in the visible area of the scene.
I could also use a primer and straightening out of my understanding of how the
pseudo-random streams work, since when I run my little test scene with a box and
a string, the string is always in the same place. What's the solution /
workaround?
#declare Message = text { ttf "arial.ttf" Attributes [2] 0.1, 0 pigment {White}
scale 1 translate < rand(FlashX), rand(FlashY), rand(FlashZ) > * 4}
#declare MinM = min_extent(Message);
#declare MaxM = max_extent(Message);
object {Avoid}
object {Message}
#if (MaxM.x > MinA.x | MinM.x < MaxA.x)
text { ttf "arial.ttf" "X Overlap" 0.01, 0 pigment {Red} translate y*1}
#end
#if (MaxM.y > MinA.y | MinM.y < MaxA.y)
text { ttf "arial.ttf" "Y Overlap" 0.01, 0 pigment {Red} translate y*0}
#end
#if (MaxM.z > MinA.z | MinM.z < MaxA.z)
text { ttf "arial.ttf" "Z Overlap" 0.01, 0 pigment {Red} translate -y*1}
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I see that the pseudorandom stream is dependent upon the seed value.
I guess what I need is a _different_, if not truly random value to pass to the
seed() generation command.
Are the noise generators "truly" random (enough) for this purpose?
I see clipka tried to access the system date/time way back when, which IIRC is
how we used to do it when I was a kid, when we used to build mechanical
computers out of dinosaur bones shaped with flint tools... :O
Is there _any_ outside, changing system value that POV-Ray SDL can access?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I guess what I need is a _different_, if not truly random value to pass to the
> seed() generation command.
It's typical to seed the random number generator based on the system
time. I'm not sure if POV offers this option, but if not you can hack
something together using the "datetime" command:
#declare mySeed = seed(val(datetime(now,"%H%M%S")));
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> > I guess what I need is a _different_, if not truly random value to pass to the
> > seed() generation command.
>
> It's typical to seed the random number generator based on the system
> time. I'm not sure if POV offers this option, but if not you can hack
> something together using the "datetime" command:
>
> #declare mySeed = seed(val(datetime(now,"%H%M%S")));
I would be careful with that, since you can never reproduce a picture using
system time as seed. Better try hand coded seeds until you have the placement as
you like it. The last one you keep. A given seed will ever produce the same
"random" sequence.
Collision detection is not implemented in POV as all I know. If you are content
to use spheres surrounding your objects you can test the distance of their
centers againt the sum of their radii. But you can not come closer with this
approximation.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 29/08/2013 17:06, scott nous fit lire :
>> I guess what I need is a _different_, if not truly random value to
>> pass to the
>> seed() generation command.
>
> It's typical to seed the random number generator based on the system
> time. I'm not sure if POV offers this option, but if not you can hack
> something together using the "datetime" command:
>
> #declare mySeed = seed(val(datetime(now,"%H%M%S")));
>
>
You are doing it the long way.
#declare mySeed = seed(now); /* only in 3.7 */
You might want to multiply now by some constant, as the unit(1) is the day.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You are doing it the long way.
>
> #declare mySeed = seed(now); /* only in 3.7 */
Ah, much better!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > #declare mySeed = seed(val(datetime(now,"%H%M%S")));
This must be a 3.7 feature. I'll update to that when I can.
> I would be careful with that, since you can never reproduce a picture using
> system time as seed.
Indeed. Though sometimes I'd like to have things be different every time if I
really want them to be. Predictably pseudorandom is obviously trivial.
Unpredictably more pseudorandomer is tricksier, My Precious. Oh yes, very
tricksy indeed.
> Better try hand coded seeds until you have the placement as
> you like it. The last one you keep. A given seed will ever produce the same
> "random" sequence.
This is indeed getting clearer. Useful to know.
> Collision detection is not implemented in POV as all I know. If you are content
> to use spheres surrounding your objects you can test the distance of their
> centers againt the sum of their radii. But you can not come closer with this
> approximation.
Clever and simple. Likely FAST, too.
Thank you ever so much for that little trick.
After a moment of reflection, I believe that better/simpler would be to limit my
placement and testing to 2D with circles, to avoid sorting out the potential
random "spheres" that would be hidden behind the stationary "spheres". _Then_
I'll translate the circle that pops out the end of the loop along z by a random
amount.
Eventually I'll work out something with bounding boxes and vector functions...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just played around a bit, since collision detection would be a nice thing. It
seems that intersections of solid objects gives a finite bounding box if there
is an intersection and an infinity one
box { <-10000000000,10000000000> }
if there is no intersection. May be one of the more experienced users here knows
the answer. It seems to work with spheres and boxes.
But one has to store all objects in an Array since one has to test every new one
against all existing. In special cases there are optimisations. May be you would
like to study the code of Jonathan Hunts "pebbles". You find the link within the
POV Hall of Fame.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I just played around a bit, since collision detection would be a nice thing. It
> seems that intersections of solid objects gives a finite bounding box if there
> is an intersection and an infinity one
>
> box { <-10000000000,10000000000> }
>
> if there is no intersection. May be one of the more experienced users here knows
> the answer. It seems to work with spheres and boxes.
>
> But one has to store all objects in an Array since one has to test every new one
> against all existing. In special cases there are optimisations. May be you would
> like to study the code of Jonathan Hunts "pebbles". You find the link within the
> POV Hall of Fame.
>
> Best regards,
> Michael
>
>
>
A simple one is to put all base objects in a single union. Those are
your environment.
Test the randomly placed objects against that union.
If you have many objects to place, after about 100, make an union with
those. Now, you only test for the static objects and that union. That
test will be much faster than testing every individual objects.
You can also use the trace function in some cases.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
