Inspired by recently posted spheres I started easy (I hope), flexible and
universal macro for placing objects. On attached image I placed 100 randomly
generated primitives inside rotated povlogo. I took 35 minutes on PII 233. It
was started with .001 accuracy - it means that deep if intersections for
placed objects is no more .001 unit. Any finite solid object can be placed.
Things like stone walls or stack of matches can be done I think. Of course it
requires CPU a lot but internally it works with functions to remove influence
of slow parsing. I have started more packed version yesterday (1000 objects in
the same povlogo) but still parses. Any comments ?

ABX

Post a reply to this message

Attachments:
Download 'filler.png' (52 KB)

Preview of image 'filler.png'

Are the tori considered bound by a cylinder, or is it possible that other
object may pass through them. I think that this macro should have switches
to limit the variety of objects and to therefore limit the number of
calculations necessary to test for intersections.

Have you guessed the calculation time for one intersection test? If this
picture parsed for 35 minutes, I can imagine that the parsing time for a
very densely packed object would be really extreme.

I have another idea for a macro which fills a plane with objects. First a
spline would need to be built that covers the entire viewing area. Each
piece would then be placed along the spline and randomly translated by some
amount. The time of each piece would be stored in an array, so that each new
piece need only to be checked against those pieces with similar or
intersecting time values.

 -Shay



news:8kj7cuccjtgn7mild2vgnss9c5nrrifetu@4ax.com...

Post a reply to this message

On Mon, 22 Apr 2002 09:55:00 -0500, "Shay" <sah### [at] simcopartscom> wrote:
> Are the tori considered bound by a cylinder, or is it possible that other
> object may pass through them.

May pass. Only volume is considered.

> I think that this macro should have switches
> to limit the variety of objects and to therefore limit the number of
> calculations necessary to test for intersections.

No need for switches. When previous element is placed then next element is
requested by call of Filler_Element macro. User have to write this macro so he
can control. It have to create next object for place and additional can
specify additional region when element shoud appear for sure. For example I
can fill glass in 75% from bottom with white spheres and top 75% with black
spheres so in middle 50% they are mixed. Only necessary number of objects are
created.

main engine is called with:

#macro Filler( Initial_Space , Accuracy , Seed , Placed_Limit , Removed_Limit)

  Initial_Space - object/container to fill
  Accuracy - Largest deep which can intersect
  Seed - 0 for regular placing should be performed
                initialized random generator for random placing 
  Placed_Limit - how many objects should be placed
  Removed_Limit - how many objects can be placed in "trash" before
               "not enogh space for placing" message

Filler() macro calls Filler_Element() macro (by user) which in case of my
example looks like

#local Elements = array[5]
#local Elements[0] = sphere{ 0 1 }
#local Elements[1] = box{ -1 1 }
#local Elements[2] = torus{ 1 .1 }
#local Elements[3] = cylinder{ -y y 1 }
#local Elements[4] = cone{ -y 1 y 0 }
#local Generator = seed(1);

#macro Filler_Element( Element )
  // define object geometry for functions
  #declare Element[ 0 ] = object{
    Rand_Array_Item(Elements,Generator)
    scale (.1 + VRand(Generator))/30
    rotate 360 * VRand(Generator)
  }
  // specify decoration
  #declare Element[ 1 ] = object{
    Element[ 0 ]
    pigment{color rgb VRand(Generator)/2+.5}
  }
  // additionaly specify space appearance if you want it
  // #declare Element[ 2 ] = sphere{ rand(Generator) 100 } 
#end



> Have you guessed the calculation time for one intersection test? If this
> picture parsed for 35 minutes, I can imagine that the parsing time for a
> very densely packed object would be really extreme.

Unfortunatelly. I plan text output so placing can be performed once.

> I have another idea for a macro which fills a plane with objects. First a
> spline would need to be built that covers the entire viewing area.

You mean screen ? In fact this is easy possible with my macro.

ABX

Post a reply to this message

> 
> Inspired by recently posted spheres I started easy (I hope), flexible and
> universal macro for placing objects. On attached image I placed 100 randomly
> generated primitives inside rotated povlogo. I took 35 minutes on PII 233. It
> was started with .001 accuracy - it means that deep if intersections for
> placed objects is no more .001 unit. Any finite solid object can be placed.
> Things like stone walls or stack of matches can be done I think. Of course it
> requires CPU a lot but internally it works with functions to remove influence
> of slow parsing. I have started more packed version yesterday (1000 objects in
> the same povlogo) but still parses. Any comments ?

Interesting, but since you mentioned a stack of matches, does it correctly
simulate the effects of gravity and collision of the objects? I presume
not since this would require a lot of quite difficult calculations and
won't work without tessellation for complicated objects.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 22 Apr 2002 18:00:06 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Interesting, but since you mentioned a stack of matches, does it correctly
> simulate the effects of gravity and collision of the objects?

No. It's filler not faller ;-)

> I presume
> not since this would require a lot of quite difficult calculations and
> won't work without tessellation for complicated objects.

I'm not tesselating anything bus sampling.

ABX

Post a reply to this message

> 
> No. It's filler not faller ;-)

All right, i was just distracted by the image of 'a stack of matches'.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 20 Apr. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

news:9898cus8vi97a6d3ibj70bm9a26516t52f@4ax.com...
>
<snip>
>

looks very useful


> You mean screen ? In fact this is easy possible with my macro.
>

Yes, but I was trying to find a way to do it as quickly as possible. If one
value (time) could give the location of an object, then testing this one
value to determine whether a more complex intersection test is necessary
might speed up parse. Of course parse time is not that big a consideration
since the macro will only need to parse once.

 -Shay

Post a reply to this message