Page MenuHomeFeedback Tracker

Fix bounding boxes
New, WishlistPublic


The commands boundingBox and boundingBoxReal are returning excessive boxes, up to the point where I can as well just take a wild guess. Chances are my box will be a better guess/match. :/

If boundingBox returns a box that includes some kind of spacing/margin by design, then that's fine, I guess. But boundingBoxReal has to return an *optimal* box (where the optimum is the minimum) - anything else is not usefull. At all.
If you're funny, introduce a new command: boundingBoxRealForReal. 8)

And secondly (minor problem): Please make it so that these commands can just take a class (string). Currently they need an object (present in the world), which kind of defeates the purpose of retrieving the bbox first (e.g. in order to find a suitable place). Sure, we can spawn stuff first somewhere else and delete (or reposition) it afterwards. But that's just a hassle, considering the bounding box of an object is *static*. And recalculating the bounding box at runtime seems to be wasteful anyways (say from a performance point of view; memory is cheap).


Legacy ID
Additional Information

See discussion:

An example (yellow = boundingBox, orange = boundingBoxReal):

Use cases doomed to be infeasible without precise/optimal bounding boxes:

  • rectangle packing (or attachTo in general)
  • proper drag'n'carry of object
  • chaining of objects (dynamic spawning of composites)
  • ...and many more.

Event Timeline

ruebe edited Additional Information. (Show Details)Jul 12 2015, 6:55 PM
ruebe set Category to Engine.
ruebe set Reproducibility to Always.
ruebe set Severity to None.
ruebe set Resolution to Open.
ruebe set Legacy ID to 1751175039.May 8 2016, 12:21 PM
ruebe added a subscriber: ruebe.
ruebe added a comment.Jul 12 2015, 6:56 PM

The following ticket might be related (maybe that's the reason for systematically shitty bounding boxes): (boundingBox and boundingBoxReal include Memory LOD)