For omniverse.

I would like to see this tested, and have the coding and usage-logic critiqued.

Perhaps there should be provision for a vector arrow, possibly with a
camera-facing constant-size text label.

Post a reply to this message

Attachments:
Download 'bounding_box.mcr.txt' (4 KB)

"Bald Eagle" <cre### [at] netscapenet> wrote:
> For omniverse.
>
> I would like to see this tested, and have the coding and usage-logic critiqued.
>
> Perhaps there should be provision for a vector arrow, possibly with a
> camera-facing constant-size text label.

Hey thanks! Got it, trying it, and going out the door so can't do anything more
with it.
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. No time right now to see what all there is to it.

Bob

Post a reply to this message

"omniverse" <omn### [at] charternet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > For omniverse.
> >
> > I would like to see this tested, and have the coding and usage-logic critiqued.
> >
> > Perhaps there should be provision for a vector arrow, possibly with a
> > camera-facing constant-size text label.
>
> 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.

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.

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.

Post a reply to this message

"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

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "omniverse" <omn### [at] charternet> wrote:
>
> (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

That's good, maybe I'm not the only one who thinks backward. Knew it must be
camera but jumped ahead of myself thinking of the object. :( Wasn't your macro,
was me doing the usual wrong thing.

> 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...

Definitely camera look_at origin, I would expect anyway, not the <0,0,0> origin.
Although a different singular line between those 2 points might be good for the
spatially challenged to keep visually oriented to a fixed "center".

Post a reply to this message

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

> Definitely camera look_at origin, I would expect anyway, not the <0,0,0> origin.
> Although a different singular line between those 2 points might be good for the
> spatially challenged to keep visually oriented to a fixed "center".

Good point about look_at.


I think that axes or gridlines, or some such thing like that would serve the
same function as the line to the origin -

although when I was writing my code for visualizing the camera view frustum, I
thought it would be good to have some sort of 3D indicator like a pilot's
dashboard.  Even better would have been a scene-in-scene box from a -N*z to z
pseudo-default camera view, with color-coded axes and an arrow or a mini
view-frustum to show a meta-scene.

IIRC, some of the wizards here have developed code to render the same scene from
multiple cameras in the same render.  That would be best.

Post a reply to this message