Skip to content
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

Add some updates as per JuliaCon Paper Review #13

Merged
merged 17 commits into from
Aug 9, 2019

Conversation

avik-pal
Copy link
Owner

@avik-pal avik-pal commented Jul 18, 2019

Changes introduced:

  • We now have detailed documentation for the entire exposed API
  • Added keyword arguments for some of the objects as they are confusing to remember
  • Added a detailed tutorial for rendering

Things to do before merging:

  • Add docs for the renderers
  • Have a more robust test suite and improve test coverage
  • Add the inverse rendering examples
  • Address the other non-software related concerns in the paper as mentioned in JuliaCon submission comments #9

@codecov
Copy link

codecov bot commented Jul 18, 2019

Codecov Report

Merging #13 into juliacon-paper will decrease coverage by 0.43%.
The diff coverage is 28.57%.

Impacted file tree graph

@@                Coverage Diff                 @@
##           juliacon-paper      #13      +/-   ##
==================================================
- Coverage           47.29%   46.85%   -0.44%     
==================================================
  Files                  18       18              
  Lines                 757      764       +7     
==================================================
  Hits                  358      358              
- Misses                399      406       +7
Impacted Files Coverage Δ
src/imutils.jl 0% <ø> (ø) ⬆️
src/renderers/rasterizer.jl 0% <ø> (ø) ⬆️
src/objects/sphere.jl 84.21% <ø> (ø) ⬆️
src/bvh.jl 0% <ø> (ø) ⬆️
src/optimize.jl 0% <ø> (ø) ⬆️
src/objects/obj_parser.jl 89.89% <ø> (ø) ⬆️
src/objects/triangle.jl 96.29% <ø> (ø) ⬆️
src/utils.jl 48.38% <ø> (+0.76%) ⬆️
src/gradients/numerical.jl 86.11% <ø> (ø) ⬆️
src/objects/polygon_mesh.jl 0% <ø> (ø) ⬆️
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f906e40...c72cf55. Read the comment docs.

.travis.yml Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
docs/src/api/differentiation.md Outdated Show resolved Hide resolved
docs/src/api/optimization.md Outdated Show resolved Hide resolved
docs/src/index.md Outdated Show resolved Hide resolved
docs/src/getting_started/teapot_rendering.md Show resolved Hide resolved
docs/src/index.md Outdated Show resolved Hide resolved
rendering by a significant amount. The main design behind an acceleration
structure should be such that it can be used as a simple replacement for
a vector of [`Object`](@ref)s.
"""
abstract type AccelerationStructure end
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm just wondering if this type is really needed (i.e., would adding methods that have a specific implementation for all acceleration structures be relevant?). It might still be useful if you plan on drawing the type hierarchy, for instance, so I'm not proposing to remove it (unless you think it makes things clearer).

Copy link
Owner Author

Choose a reason for hiding this comment

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

would adding methods that have a specific implementation for all acceleration structures be relevant?

No, we can't have a specific implementation relevant to all acc. structures

This type is simply so that we have a clean type hierarchy.

src/bvh.jl Outdated
"""
BoundingVolumeHierarchy

Construct the Bounding Volume Hierarchy from a given Vector of
Copy link
Contributor

Choose a reason for hiding this comment

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

You're documenting a type, not a function, so you can't say that you "construct the BVH". "A BVH hierarchy"?

This piece of documentation might be moved to line 63 (function BoundingVolumeHierarchy(scene::Vector)).

(BTW, why are you using an erased type Vector? Can't you be more precise, like Vector{<:Triangle}?)

@@ -28,5 +35,10 @@ end
zeroonenorm(x::AbstractArray)

Normalizes the elements of the array to values between `0` and `1`.

Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't you then remove this workaround and upgrade Zygote in your Project.toml?

Copy link
Owner Author

Choose a reason for hiding this comment

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

The main issue is there are some blocking issues on Zygote's end that prevent me from updating it. Even if it is easy to workaround on the end of RayTracer, those changes cause segfault in case of Duckietown.

@avik-pal avik-pal marked this pull request as ready for review August 1, 2019 01:01
@avik-pal
Copy link
Owner Author

avik-pal commented Aug 9, 2019

I am merging this PR for now. Will update the test suite in a later PR.

@avik-pal avik-pal merged commit 75d1859 into juliacon-paper Aug 9, 2019
@avik-pal avik-pal deleted the review_updates branch August 9, 2019 08:29
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