 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been told, again and again, that there is no generic collision detection in
povray. While I suppose that's true (you can't really tell if one object is
intersecting another) there's still the [trace] function, and the [inside] and
[outside] functions.
Supposing that a tree generation macro took in a location, the age of the tree,
and an array of elements to test against, how hard would it be to grow a tree in
a given location, accounting for interference from the listed elements?
If interference is deemed likely, or imminent, the limb in question (treated as
a vector) could be pruned or deflected. (this would likely be the difficult
part)
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I've been told, again and again, that there is no generic collision detection in
> povray. While I suppose that's true (you can't really tell if one object is
> intersecting another) there's still the [trace] function, and the [inside] and
> [outside] functions.
>
> Supposing that a tree generation macro took in a location, the age of the tree,
> and an array of elements to test against, how hard would it be to grow a tree in
> a given location, accounting for interference from the listed elements?
>
> If interference is deemed likely, or imminent, the limb in question (treated as
> a vector) could be pruned or deflected. (this would likely be the difficult
> part)
>
> A.D.B.
>
>
>
Pruning or deflecting a branch would be the easy part. The hard part is
to detect when to do so.
For each new segment, you need to check every other and test wether or
not the new one would intrude into another.
Anyway, in real life, there are uncommon cases when plants self
collide/intersect. In that case, the affected branches/roots can merge
together.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
At any rate, I'm more concerned with preventing interference with design
elements at the moment.
I've been working on an Idea that target elements could be separated into zones
of probability according to distance from the point of origin.
Without generic collision detection built into povray, collisions between
adjacent trees would be impossible to detect.
A.D.B.
Alain <aze### [at] qwerty org> wrote:
> > I've been told, again and again, that there is no generic collision detection in
> > povray. While I suppose that's true (you can't really tell if one object is
> > intersecting another) there's still the [trace] function, and the [inside] and
> > [outside] functions.
> >
> > Supposing that a tree generation macro took in a location, the age of the tree,
> > and an array of elements to test against, how hard would it be to grow a tree in
> > a given location, accounting for interference from the listed elements?
> >
> > If interference is deemed likely, or imminent, the limb in question (treated as
> > a vector) could be pruned or deflected. (this would likely be the difficult
> > part)
> >
> > A.D.B.
> >
> >
> >
>
> Pruning or deflecting a branch would be the easy part. The hard part is
> to detect when to do so.
> For each new segment, you need to check every other and test wether or
> not the new one would intrude into another.
>
> Anyway, in real life, there are uncommon cases when plants self
> collide/intersect. In that case, the affected branches/roots can merge
> together.
>
>
> Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye wrote:
> Supposing that a tree generation macro took in a location, the age of the tree,
> and an array of elements to test against, how hard would it be to grow a tree in
> a given location, accounting for interference from the listed elements?
Testing against a list of successful branch objects and performing
inside/outside/trace operations on all of them can become very slow.
You may be able to create a 3D array that is the space in which the tree
grows. Each time a branch is made, fill that part of your 3D array in
with positive values. Wherever a new branch is supposed to go, test
against the cells in that area. If the cells are 0, then your branch can
go there.
If you can get away with a low-res array, then this method should be
pretty fast to compute as you just need to test against (and write to) a
shared space. But there will be some trickery involved when
approximating each branch as a voxel representation... To get something
like this to work, you might want to find out how to make Bresenham
lines in 3D space, particularly ones with variable padding.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
stbenge <myu### [at] hotmailcom> wrote:
> Anthony D. Baye wrote:
> > Supposing that a tree generation macro took in a location, the age of the tree,
> > and an array of elements to test against, how hard would it be to grow a tree in
> > a given location, accounting for interference from the listed elements?
>
> Testing against a list of successful branch objects and performing
> inside/outside/trace operations on all of them can become very slow.
>
> You may be able to create a 3D array that is the space in which the tree
> grows. Each time a branch is made, fill that part of your 3D array in
> with positive values. Wherever a new branch is supposed to go, test
> against the cells in that area. If the cells are 0, then your branch can
> go there.
>
So, to begin, I would run a sampling loop over the bounding boxes of the target
objects to mark their locations within the 3d-array?
> If you can get away with a low-res array, then this method should be
> pretty fast to compute as you just need to test against (and write to) a
> shared space. But there will be some trickery involved when
> approximating each branch as a voxel representation... To get something
> like this to work, you might want to find out how to make Bresenham
> lines in 3D space, particularly ones with variable padding.
>
Thanks for the advice, I'd never heard of Bresenham's algorithm before. It
requires bit-shifting, so I'm not sure how an application of this nature would
work within the confines of the SDL.
Although...
It might be possible to output a file containing a representation of the csg
objects in 3d-space (similar to a df3, perhaps. I'm currently working on a
program that could do just that using orthogonal slices of an object), which
could then be read into a 3d array by a secondary utility which would read the
data into a 3d-array and build the tree as an include file.
It might, actually, be greatly simplified that way.
thoughts?
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anthony D. Baye wrote:
> Thanks for the advice, I'd never heard of Bresenham's algorithm before. It
> requires bit-shifting, so I'm not sure how an application of this nature would
> work within the confines of the SDL.
You can do almost anything with POV's SDL. The Bresenham algorithm is
entirely possible.
> Although...
>
> It might be possible to output a file containing a representation of the csg
> objects in 3d-space (similar to a df3, perhaps. I'm currently working on a
> program that could do just that using orthogonal slices of an object), which
> could then be read into a 3d array by a secondary utility which would read the
> data into a 3d-array and build the tree as an include file.
Which objects are you testing against? Environmental elements such as
buildings, which will deflect branches? I guess I was assuming that you
wanted to keep branches from intersecting other branches. If all you
want to do is keep branches from intersecting with an environment, then
your job will be easy(ish), and you won't want to bother with the method
I previously mentioned.
To detect collisions with an environment, I would definitely use
trace(). Make the simplest representation of the environment you can,
and make it a union. You will always test against that union. For each
new branch, trace() a ray from the beginning of that branch, extending
out in the direction of growth. If the ray doesn't make contact with the
environment, make a branch at the full target length. If it does make
contact, find the length of the ray you just shot and make a branch no
longer than that length.
> thoughts?
Whichever way is easier for you is the method you want to use :)
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been playing with tree generation that uses a reverse binary
method. You start with the tips of the limbs and work your way back to
the trunk. It' binary because each branch point uses two of the previous
points or branches of the tree. As an example if you chose 16 tips then
you'll have 8 branches then 4 branches and so on till you reach the
trunk. With this method you have an option to place the end of the
branches anywhere you want.
With a little playing You should get what ya need.
I belive I have a copey at http://leroywhetstone.s5.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
