Skip to content

Extension of ovus to: #306

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

Merged
merged 2 commits into from
Sep 20, 2017

Conversation

LeForgeron
Copy link
Contributor

  • allow the center of the top sphere to not be on the top of the bottom sphere (via "distance xxx")"
  • allow the radius of the torus spindle to be manually specified (via "radius xxx")
  • allow precision of the root solver to be tuned ( via "precision xxx")
    And change of UV-Mapping to be similar to the uv-mapping of cone & cylinder

* allow the center of the top sphere to not be on the top of the bottom sphere (via "distance xxx")"
* allow the radius of the torus spindle to be manually specified (via "radius xxx")
* allow precision of the root solver to be tuned ( via "precision xxx")
And change of UV-Mapping to be similar to the uv-mapping of cone & cylinder
* }
*
* The so long awaited 'Egg' forms.
*
* Normally, the bottom_radius is bigger than the top_radius
* the center of the top sphere is at the zenith of the bottom sphere
* the center of the top sphere is at the zenith of the bottom sphere, unless
* a greater distance d is specified with "distance"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the distance d an offset to the default position, or the Y(?) coordinate of the top sphere's center?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the distance from the origin, it must be at least the radius of the bottom sphere, but can be bigger (previously, it was always the radius of the bottom sphere)

Copy link
Contributor

@c-lipka c-lipka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor cosmetic gripes, but also one medium gripe about what I'd consider dirty coding (using float as boolean expression), and one major gripe about a test that looks positively wrong to me). Please do fix/double-check at least the latter two.

@@ -820,9 +827,15 @@ void Ovus::Compute_BBox()
{
biggest = TopRadius;
}
// handle degenerated ovus in sphere
if (!BottomRadius)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please replace this with a proper test. BottomRadius is a float, not a boolean, so test should be either exact comparison with 0.0 or of style fabs(...) < EPSILON. Also, check whether this shouldn't actually be a less-or-equal rather than an equal test.

return;
if ((P[Y]>EPSILON)&&(P[Y]<(VerticalSpherePosition-EPSILON)))
{
// when not on a face, the range 0.25 to 0.75 is used (just plain magic 25% for face, no other reason, but it makes C-Lipka happy)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you really want to make C-Lipka happy, please amend this comment ;)

Dividing at 1/4 and 3/4 has the advantage of the division being exactly at a pixel boundary if the texture is an image 2^N by 2^M pixels in size, which is common for image textures originally designed for mesh-based renderers. It also happens to work for 20N by 20M pixels, which is common for image textures with "arbitrary" sizes.


if (len == 0.0)
return;
if ((P[Y]>EPSILON)&&(P[Y]<(VerticalSpherePosition-EPSILON)))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we get a bit more clarity in this expression (and a few others) by more liberal use of whitespace?

Make_BBox(BBox, -biggest, -BottomRadius, -biggest,
2.0 * biggest, 2.0 * BottomRadius + TopRadius, 2.0 * biggest);
Make_BBox(BBox, -biggest, bottom, -biggest,
2.0 * biggest, length, 2.0 * biggest);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please indent to after opening brace (same as it was before) for clarity.

else if (P[Y]>EPSILON)
{
// aka P[Y] is above VerticalSpherePositon, use TopRadius, from 0% to 25%
phi = 0.0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please stick to a 4-blanks indent.
Also, please indent the comment inside the braces.

y /= len;
z /= len;
// aka P[Y] is below origin (<0), use BottomRadius, from 75% to 100%
phi = 1.0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent, see above

phi = 1.0;
if (BottomRadius)
{
t = ((BottomRadius+P[Y])/(BottomRadius));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent, see above

}
else if (TopRadius)
{
// degenerate ovus in sphere
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indent, see above

distance = Object->ConnectingRadius - Object->BottomRadius;
Object->BottomVertical = -Object->VerticalPosition * Object->BottomRadius / distance;
}
Error("distance of Ovus must be greater than bottom radius");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Shouldn't the ovus object also work with a lower VSP, provided VSP+TR > BR?

@c-lipka
Copy link
Contributor

c-lipka commented Jul 6, 2017

From what I see here, when you created the pull request you seem to have checked a box granting reviewers (such as myself) write access to the branch corresponding to the pull request (feature-extended-ovus in your fork of the GitHub repo), allowing them to directly modify your pull request; let me know if this was intentional or otherwise.

Also note that any further commits you push to the feature-extended-ovus branch will automatically be picked up as amendments to this pull request.

@LeForgeron
Copy link
Contributor Author

From what I see here, when you created the pull request you seem to have checked a box granting reviewers (such as myself) write access to the branch corresponding to the pull request (feature-extended-ovus in your fork of the GitHub repo), allowing them to directly modify your pull request; let me know if this was intentional or otherwise.

Not intentional, probably default, but welcomed.

Also note that any further commits you push to the feature-extended-ovus branch will automatically be picked up as amendments to this pull request.

Ok, might work on it tomorrow, if I still need to.

@c-lipka c-lipka merged commit e39f5af into POV-Ray:release/v3.8.0 Sep 20, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants