I've been working with a tutorial on the trace() function in conjunction
with a random placement macro.  I'm getting some great results, but I was
wondering: Is there any way to make my macro take into account the objects
it's already placed on the surface, such that there would not be any
overlaps?  I'd like to be able to  have the objects pile up as more of them
are generated.

Regards,

A.D.B.

Post a reply to this message

Anthony D. Baye wrote:
> I've been working with a tutorial on the trace() function in conjunction
> with a random placement macro.  I'm getting some great results, but I was
> wondering: Is there any way to make my macro take into account the objects
> it's already placed on the surface, such that there would not be any
> overlaps?  I'd like to be able to  have the objects pile up as more of them
> are generated.

  You can declare an union with copies of the placed objects, without 
using it on the scene, just for trace() test purposes on next calls to 
the macro.

--
Jaime

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> I've been working with a tutorial on the trace() function in conjunction
> with a random placement macro.  I'm getting some great results, but I was
> wondering: Is there any way to make my macro take into account the objects
> it's already placed on the surface, such that there would not be any
> overlaps?  I'd like to be able to  have the objects pile up as more of them
> are generated.
>
> Regards,
>
> A.D.B.

That's a good idea. I keep thinking that there's a demo file included with
POV-Ray of alphabet blocks stacked up that might be useful to look at.

Post a reply to this message

Anthony D. Baye <Sha### [at] spamnomorehotmailcom> wrote:
> Is there any way to make my macro take into account the objects
> it's already placed on the surface, such that there would not be any
> overlaps?

  Generic collision detection is almost impossible.

  However, you can make it so that if the distance between the new object
to be placed to any of the other objects is smaller than a certain distance,
you don't place the object there.
  This, of course, requires that you keep the locations of the objects
in an array and you make the check using that.

-- 
                                                          - Warp

Post a reply to this message

"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> I've been working with a tutorial on the trace() function in conjunction
> with a random placement macro.  I'm getting some great results, but I was
> wondering: Is there any way to make my macro take into account the objects
> it's already placed on the surface, such that there would not be any
> overlaps?  I'd like to be able to  have the objects pile up as more of them
> are generated.
>
> Regards,
>
> A.D.B.

Do you know you can add to a union? Here's an example from one of my Penrose
triangle scenes.

//---------------------------------------------------

#debug "\nIgnore following warning, this union intentionally empty\n"
#declare Null = union{}
#debug "Ignore previous warning, this union intentionally empty\n"

#declare SetT = Null;

#macro AddTri(A,B,C) #declare SetT = union{object{SetT} Tri(A,B,C)} #end

//---------------------------------------------------

Also take a look at these POV standard scenes:
 advanced/gaussianblob.pov by Greg M. Johnson (& Rico Reusser).

and

 advanced/blocks/makestacks by Gilles Tran, derived from work by John Van
Sickle and Christoph Hormann, although this one has bits I don't quite
follow myself as yet... :)

I hope this helps.

Post a reply to this message

PM 2Ring wrote:
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> 
>>I've been working with a tutorial on the trace() function in conjunction
>>with a random placement macro.  I'm getting some great results, but I was
>>wondering: Is there any way to make my macro take into account the objects
>>it's already placed on the surface, such that there would not be any
>>overlaps?  I'd like to be able to  have the objects pile up as more of them
>>are generated.
>>
>>Regards,
>>
>>A.D.B.
> 
> 
> Do you know you can add to a union? Here's an example from one of my Penrose
> triangle scenes.
> 
> //---------------------------------------------------
> 
> #debug "\nIgnore following warning, this union intentionally empty\n"
> #declare Null = union{}
> #debug "Ignore previous warning, this union intentionally empty\n"
> 
> #declare SetT = Null;
> 
> #macro AddTri(A,B,C) #declare SetT = union{object{SetT} Tri(A,B,C)} #end
> 
> //---------------------------------------------------
> 
> Also take a look at these POV standard scenes:
>  advanced/gaussianblob.pov by Greg M. Johnson (& Rico Reusser).
> 
> and
> 
>  advanced/blocks/makestacks by Gilles Tran, derived from work by John Van
> Sickle and Christoph Hormann, although this one has bits I don't quite
> follow myself as yet... :)
> 
> I hope this helps.
> 
> 
What purpose does that serve, besides an annoying error message?  I fail 
to see how you could even get such a scene to parse without shutting 
down - you've declared the same parameter twice.

Regards,

A.D.B.

Post a reply to this message

> What purpose does that serve, besides an annoying error message?  I fail
> to see how you could even get such a scene to parse without shutting
> down - you've declared the same parameter twice.

In POV-Ray, "declare" is more like a "set" statement; there's no real
declaration of variables. So

#declare myvar = 1;
#declare myvar = myvar + 1;

is perfectly fine, and myvar will have the value 2.

Aside from that, his example isn't complete as it doesn't include the Tri()
macro, but it illustrates how to add objects to a union one at a time. By
tracing against the union, you can do collision detection against previously
placed objects.

The flaw with this approach is that the union isn't optimized with a
bounding box heirarchy or anything, which means that as more objects are
added it will start to get slow to trace().

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

PM 2Ring wrote:
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> 
>>I've been working with a tutorial on the trace() function in conjunction
>>with a random placement macro.  I'm getting some great results, but I was
>>wondering: Is there any way to make my macro take into account the objects
>>it's already placed on the surface, such that there would not be any
>>overlaps?  I'd like to be able to  have the objects pile up as more of them
>>are generated.
>>
>>Regards,
>>
>>A.D.B.
> 
> 
> Do you know you can add to a union? Here's an example from one of my Penrose
> triangle scenes.
> 
> //---------------------------------------------------
> 
> #debug "\nIgnore following warning, this union intentionally empty\n"
> #declare Null = union{}
> #debug "Ignore previous warning, this union intentionally empty\n"
> 
> #declare SetT = Null;
> 
> #macro AddTri(A,B,C) #declare SetT = union{object{SetT} Tri(A,B,C)} #end
> 
> //---------------------------------------------------
> 
> Also take a look at these POV standard scenes:
>  advanced/gaussianblob.pov by Greg M. Johnson (& Rico Reusser).
> 
> and
> 
>  advanced/blocks/makestacks by Gilles Tran, derived from work by John Van
> Sickle and Christoph Hormann, although this one has bits I don't quite
> follow myself as yet... :)
> 
> I hope this helps.
> 
>
Thanx.

	After a little thought, I was able to implement a stacking function 
based largely off the code snip you posted. I am, however, still getting 
some overlap.  I think it's going to have to be a combination of the two 
methods suggested.
	I need to figure out a way to trick the macro into thinking that the 
object's bounds extend a minimum distance (Laterally) from the actual 
object.  Can this be done by setting the bounding box manually?  If so, 
how is this accomplished?

I've posted a test render in P.B.I.

Regards,

A.D.B.

Post a reply to this message

Anthony D. Baye wrote:
>     After a little thought, I was able to implement a stacking function 
> based largely off the code snip you posted. I am, however, still getting 
> some overlap.  I think it's going to have to be a combination of the two 
> methods suggested.
>     I need to figure out a way to trick the macro into thinking that the 
> object's bounds extend a minimum distance (Laterally) from the actual 
> object.  Can this be done by setting the bounding box manually?  If so, 
> how is this accomplished?

I think you'll need to run four traces per cube for each of the corners 
on the XZ plane. (and if you're rotating, you might want to add more 
traces along each side ..)

You can then take the higest Y of the four traces as the lowest your 
object can be at that point. If you ignore balancing, that's where to 
place your next cube. If you want to take balancing into account, I 
reckon you're screwed .. consider this:

   +---+
   |   |
   +---+
+---+
|   |
+---+

That would probably balance OK. But then if you go up another level:

     +---+
     |   |
     +---+
   +---+
   |   |
   +---+
+---+
|   |
+---+

it's clearly going to topple the middle one off the stack as well as the 
top one. And once you've placed it, you can't move it (unless you're 
working with an array which you'll later render) and the correct 'fall' 
might be this:

      _-+
     +   \
      \  _+
+---+ +- +---+
|   |    |   |
+---+    +---+

which is all the harder :)


Personally, I'd either be positioning them all by hand, ignoring balance 
or calculating falls externally (like a perl or C program)

Cheers!
Rick Measham

Post a reply to this message