-
Notifications
You must be signed in to change notification settings - Fork 930
Removed bounding_box calls with magic numbers #770
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wrong to me. In the constructor, we compute the bbox of the rotated object and store it in
this->bbox
. Here we compute the original (unrotated) geometry bbox and return that instead, clobbering the computed bbox.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see what's going on. The rotated object is constructed with a given rotation angle, so is constant ever after. The rotated object, however, may be time-varying.
Given this, we can't compute the bounding box of the child object in the constructor, since we have no time parameters at construction. Even if we did, there's no point, because the
bounding_box
method takes some (possibly different) time parameters. So we need to recompute the bounding box on every call.Thus:
bbox
member from the class in addition to thehasbox
flag. They're both unusable.rotate_y::bounding_box()
method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The end result will be that the body of
rotate_y::bounding_box()
will end up looking a lot like what the constructor currently looks like.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this is pretty much the way that the
translate
class operates.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh.
Wait.
There's a discrepancy here. Like, a big one.
A ray has a specific time value. So a hit result samples the object over time. However,
bounding_box()
methods take a range of times. Thus, they must yield the bounds of the object over that range, as opposed to a tight bounds for a specific instance in time.That range of time is the range of time values for the entire rendering, and is thus invariant. Therefore, we should know the time range at object construction, and can safely cache the result. So
rotate_y
is actually the way that things should be, except that it hard-coded the time range.translate
incorrectly recomputes the bounding box over and over for every query — the time range is always the same, and therefore the result should just have been cached at construction and returned.But that means that logically, every hittable should take the time range as parameters to their constructor. Which would be a major change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change is screwed, and should be lumped in with the other bounding-box work slated for v4.0.0.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another possible (major) design approach, which is that instead of every hittable taking a time range in the constructor, they have a
set_time_range()
method. For most simple primitives, a no-op. For time-varying primitives, this sets the time range, which will be used bybounding_box()
. For hittables that contain children, they proxy theset_time_range()
call to each child, and possibly compute and cache their bounding box. (The bounding box could be memoized in thebounding_box()
method, but no point doing that on each call;bounding_box()
might be called many times, whileset_time_range()
should be called only once.Just a thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarifying the comment above, just prior to scene render, you'd call
set_time_interval()
(better name thanset_time_range()
) on the root of the scene, to set up the scene graph once prior to rendering, after the scene time interval is known. Prior to rendering the second frame, you'd callset_time_interval()
with arguments for the second frame.