"omniverse" <omn### [at] charternet> wrote:

> > Did get to see the bounding box on unmoved WRook from my earlier post... after I
> > added colors.inc, of course. But my fast test of relocating it left that box
> > behind.

Yes, now that you point that out, I suppose that defining colors as rgb ought to
be something I get in the habit of doing with macros, so that they aren't
dependent on include files.  I should probably do pretty much the same with the
wire_box.

> Um. Dumb mistake. I translated only the final object statement, not for #declare
> one. Changed those around and bounding box stays with it.
> I was trying it too quick without realizing what went wrong.

Yes.  The object name holds onto what it was declared to be.
any further changes ought to be done much like a #declare N = N+!;
so:
#declare Object = object {Object translate <x, y, z>};
That ought to keep things nice & readable in your code, and allow the macro to
still use the Object definition as an argument.

> However, maybe I'm confused about Location.
> If I use it for object translate the wireframe thins out too much to see, yet if
> Vector is used instead it remains very visible.
>
> I was guessing Location to be for the object, if given that, but it works for
> camera location as long as Vector is given to the object.

Yes, sorry - I could been more clear about that.
The Location vector is for the camera.  I figured that if you had more than one
object in the scene, that the camera vector would be the thing to use as a
reference, and the bounding box coordinates, being calculated by the macro
anyway, would not be something that needed to be supplied by the user.

(Also: If you needed the macro to know where the object is - why would you be
required to supply that [unknown location] as a Location() vector?)

I made a small edit to the comments:
// If a camera vector variable "Location" is defined, use automatic parameters
for bounding box wire thickness

Thanks for giving this a spin.
Let me know if you find any other improvements that could be made, or just
things to make it nicer and more usable.
It's sometimes hard to strike a balance between compactness and speed, and
flexibility.

Do you think a line from the origin to the object would be useful?  Or from the
center of the screen to the object...?
There could be testing to see if the center of the object lay inside the view
frustum (given a user-supplied z-depth, or a default value) and then the macro
would only draw such a line if the object were not visible.
But the line might help if your object "disappeared" because it sneakily got
placed behind a bigger object...

Post a reply to this message