cstatz / blazert Goto Github PK

Is your feature request related to a problem? Please describe.
The CI currently does not build the examples; however, it would be highly beneficial to verify that the examples still build even after changing stuff. This is especially relevant when changing API related things.

Describe a possible solution.
This change is rather simple. Just add the appropriate flags to the cmake script in the travis config.

Describe alternatives you've considered
Alternatively, we end up with plenty of potentially non-working examples for each PR.

Is your feature request related to a problem? Please describe.
New primitive: Box of arbitrary size -> can be constructed by 6 planes, but would be beneficial to have this kind of setup in order to speed up traversal. Furthermore, setting up a box via planes is cumbersome if done every time a box is needed.

Describe a possible solution.

• Create 6 planes which construct the box
• call intersect for such a contsruct

Describe alternatives you've considered
Setting up 6 individual planes, which is error prone.

**Needed: **

• box blazeRT primitive

• box as embree primitive

• testing for blazeRT box

• testing for embree box

• support in blazertscene

• support in EmbreeScene

• testing of scene functions

Description
To increase the clarity in the API we should aim to remove all boolean variables in all function calls by appropriate enum classes in order to remove ambiguity. This will lead to less error prone usage of the code for all users. It also stated intent much clearer.

Currently, this is only the case for the constructor of Ray, which is easily fixed.

This issue is inspired by the points made in this talk.

I will introduce concepts into the code base during the next weeks.

This will greatly improve error messages and clarity of the code w.r.t. to the template parameters.
examples:
T -> std::floating_point
Collection -> requires primitive_from_collection
...

Is your feature request related to a problem? Please describe.
A plane primitive would be useful.

Describe a possible solution.
Planes are highly useful primitives for canonical examples or walls for indoor ray tracing.

Describe alternatives you've considered
A mesh could possibly do as well, but is much more computationally expensive.

We need simple and verifiable test cases for the TriangleMesh<T> implemented in blazert/primitives/trimesh.h

Simliar to the tests for the other primitives, we need tests regarding the bounding box, centers and intersections for a TriangleMesh with only 1 triangle. (easiest case imaginable)

Second, for the intersections we need tests with more complicated triangle meshes (e.g. found in test_helpers.h.

Summary:

• 1 triangle

  • bounding box
  • centers
  • intersections

• real triangle mesh

  • intersections

Is your feature request related to a problem? Please describe.
A description of the build process on widows is missing.
Windows build differs from linux/macos. It is sometime not easy to get code to compile on windows that was primarily developed on linux or macos.

Describe a possible solution.
Write a README document specifically addressing the build process on windows.

test for following stuff:

• reflect and refract do not seem to be doing the right thing...(https://en.wikipedia.org/wiki/Snell%27s_law#Vector_form)..including the inputs into these functions in main..

Describe the enhancement
Use the current version of

• tiny_object_loader and
• stb_write_image

in order to be up-to-date. I was just trying to fix compiler warnings in both files included with blazeRT but first, we should try to use up-to-date versions.

Describe the enhancement
Currently, the variables int cmake/build_options.cmake do not use a prefix which might lead to collision when using the library in conjunction with others.

Is your feature request related to a problem? Please describe.
Provide an interface to query the (closest-) distance to the surface from any point in space in or surrounding the scene, preferable using the already existing acceleration structures. This kind of query is useful in many applications involving inhomogeneous materials.

Describe a possible solution.
Implement a distance to surface function for each primitive. Implement a distance traversal for the bvh (check if point is inside bounding box of node).

Describe alternatives you've considered
Using a library that provides the acceleration structured and queries for the primitives.

Additional context
The query would be available in the scene api and provide the prim_id, geom_id, closest_point and closest_distance.

Describe the bug
For each hit, a prim_id is returned; however, prim_id is not unambiguous if more than one geometry type exists in the scene.

To reproduce

1. Create a scene
2. create 2 cylinders, and 2 sphere
3. color each prim_id differently
   Result: two pairs of same-colored spheres and cylinders

Expected behavior
I would expect an unambiguous id in order to differentiate between all geometries, so in the context of blazeRT probably something along the lines of std::pair<unit32_t, uint32_t> for geom_id and prim_id which would allow for a correct mapping. There are probably better solutions than std::pair but the idea remains the same

Is your feature request related to a problem? Please describe.
Installing blazert could be much easier if packages would be provided.

Describe a possible solution.
Providing packages for various package managers would be beneficial for the user of the library:

• vcpkg
• conan
• homebrew
• AUR
• .dev
• .rpm
• (windows installer)

Describe alternatives you've considered
Keep manually installing via cmd.

Additional context
Two AUR packages for blazert have been created for the main release branch as well as the develop branch:

• https://aur.archlinux.org/packages/blazert/
• https://aur.archlinux.org/packages/blazert-git/

Is your feature request related to a problem? Please describe.
Currently there is no or little documentation of the API.

Describe a possible solution.
At least a proper documentation of the High-Level-(Scene-)API should be created.
From the source-code documentation a tex, html or md document should be created.

Describe alternatives you've considered
Just let the developer figure this out.
Generate a API for all functions, classes, types.

Python bindings would be beneficial for use cases outside of EM. Could also be helpful for prototyping and debugging, e.g. prototyping Ray Material interaction, etc

Is your feature request related to a problem? Please describe.
A cylinder primitive would be useful.

Describe a possible solution.
Planes are highly useful primitives for canonical examples or columns in indoor ray tracing. Could also be beneficial for on-top em applications when considering simulations of pipes

Describe alternatives you've considered
A mesh could possibly do as well, but is much more computationally expensive.

Describe the enhancement
The structure for the test cases needs to be clearer. Some files contain 2k LOC which is way too much to keep an overview over whats tested and where to add new things.

Expected behavior
Primitives should get their own directory with multiple files named after what's being tested.

Is your feature request related to a problem? Please describe.
You should not reinvent the wheel. Use stl datatypes if they solve your problem.

Describe a possible solution.
Replace custom stack class with std::array.

Describe the bug
Usage with VisualStudio 2022 seems problematic

System
Which OS, compiler, and compiler version are you using:

• OS: Windows10
• Compiler and version:

Additional context
Additional documentation is needed, e.g. regarding the installation of the visual studio english language pack.

Is your feature request related to a problem? Please describe.
In order to test if you are inside or outside a given geometry or primitive (-collection), counting the number of intersections for a given range of primitives (by prim_id and geom_id) is necessary.

Describe a possible solution.
Provide an interface (scene api) that can count the number of intersections for a ray query (possibly a number of intersections traversal function (that can be give a geom_id and prim_id-range)).

Describe alternatives you've considered
Leave this up to the user.

Additional context
This function would be called infrequently (it is used to test whether or not a source or sink is inside a given object).

Description

There are plenty of warnings which are currently not caught. We should add at least -Wpedantic and -Wsign-conversion to the warning flags.

Generally, we should aim to catch as many warning as possible. The list can be inspired by https://github.com/lefticus/cpp_starter_project/blob/master/cmake/CompilerWarnings.cmake

Expectation

This will lead to better code quality with fewer (potential) bugs.

We need test cases for blazeRT, at least with respect to the following functions

bvh/aabb.h:

• intersect_node

bvh/accel.h:

• intersect_leaf
• traverse

bvh/bbox.h:

• GetBoundingBox
• compute_bounding_box

primitives/trimesh.h:

• intersect
• update_intersector (optional)
• prepare_traversal (optional)
• post_traversal (optional)

Feel free to add additional testing in case I missed any functions.

Describe the bug
For sphere, cylinder and plate primitives only one object per BVH is traced apparently, no matter how many primitives are actually in the tree..

System
Which OS, compiler, and compiler version are you using:

• OS: Arch Linux
• Compiler and version: clang10, gcc10

To reproduce

#include <blazert/blazert.h>
#include <blazert/datatypes.h>
#include <iostream>
#include <memory>
#include <vector>

#define STB_IMAGE_WRITE_IMPLEMENTATION
#include "stb_image_write.h"

using ft = double;

void SaveImagePNG(const char *filename, const float *rgb, int width,
                  int height) {
  auto *bytes = new unsigned char[width * height * 3];
  for (int y = 0; y < height; y++) {
    for (int x = 0; x < width; x++) {
      const int index = y * width + x;
      bytes[index * 3 + 0] = (unsigned char) std::max(
          0.0f, std::min(rgb[index * 3 + 0] * 255.0f, 255.0f));
      bytes[index * 3 + 1] = (unsigned char) std::max(
          0.0f, std::min(rgb[index * 3 + 1] * 255.0f, 255.0f));
      bytes[index * 3 + 2] = (unsigned char) std::max(
          0.0f, std::min(rgb[index * 3 + 2] * 255.0f, 255.0f));
    }
  }
  stbi_write_png(filename, width, height, 3, bytes, width * 3);
  delete[] bytes;
}

int main(int argc, char **argv) {
  int width = 8192;
  int height = 8192;

  // the properties of the cylinders need to be saved on the heap
  auto centers = std::make_unique<blazert::Vec3rList<ft>>();
  auto semi_axes_a = std::make_unique<std::vector<ft>>();
  auto semi_axes_b = std::make_unique<std::vector<ft>>();
  auto heights = std::make_unique<std::vector<ft>>();
  auto rotations = std::make_unique<blazert::Mat3rList<ft>>();

  blazert::Mat3r<ft> rot{
      {0, 0, 1},
      {0, 1, 0},
      {-1, 0, 0}};

  /***
   * Each cylinder adds an element to the std::vectors containing the corresponding parameters
   */
  // cylinder 1 (this one is plotted)
  centers->emplace_back(blazert::Vec3r<ft>{-3, 3, 0});
  semi_axes_a->emplace_back(1);
  semi_axes_b->emplace_back(1);
  heights->emplace_back(1);
  rotations->push_back(rot);

  // cylinder 2 (this one is not plotted)
  centers->emplace_back(blazert::Vec3r<ft>{1, 4, 0});
  semi_axes_a->emplace_back(0.5);
  semi_axes_b->emplace_back(0.5);
  heights->emplace_back(2);
  rotations->push_back(rot);

  blazert::Scene<ft> scene;
  scene.add_cylinders(*centers, *semi_axes_a, *semi_axes_b, *heights, *rotations);
  scene.commit();

  // structure to save the colors
  std::vector<float> rgb(width * height * 3, 0.0f);

#ifdef _OPENMP
#pragma omp parallel for schedule(dynamic, 1)
#endif
  for (int y = 0; y < height; y++) {
    for (int x = 0; x < width; x++) {

      const blazert::Ray<ft> ray{{0.0, 5.0, 20.0}, {static_cast<ft>((x / ft(width)) - 0.5), static_cast<ft>((y / ft(height)) - 0.5), ft(-1.)}};
      blazert::RayHit<ft> rayhit;

      const bool hit = intersect1(scene, ray, rayhit);
      if (hit) {
          rgb[3 * ((height - y - 1) * width + x) + 0] = float(1);
          rgb[3 * ((height - y - 1) * width + x) + 1] = float(0);
          rgb[3 * ((height - y - 1) * width + x) + 2] = float(0);
      }
    }
  }

  SaveImagePNG("render.png", &rgb.at(0), width, height);

  return 0;
}

Expected behavior
I would expect two cylinders to be drawn, but only the first one shows up

Additional context
If I add a debug log to test_lead_nodes to print the num_primitives it only shows up as "1" all the time.

Describe the enhancement
The examples should be reworked at some point in time to reduce code duplication and especially to make it easier to fix the warnings.

E.g. using ft = double and partially templated code in combination with float inputs for the geometry leads to some type conversion warnings which are tedious to fix.

Expected behavior
I think there are two options:

1. remove templates and use float for everything
2. templatize everything and use static_casts where appropriate.

The end goal would be to get rid of all warnings during the compilation of the code.

Currently, precision tests for triangles and triangle meshes are done in test_trimesh.cpp. This isn't really the place for such tests since this is not really unit-testing.

We should refactor this and create an extra target which provides an executeable to be run on the target system which reports the precision.

See blazert/embree/scene.h:

1. add_spheres, add_planes, add_cylinders only adds the first object currently
2. return geomID of this object
3. all other objects in vectors will be ignores

This has to change in some way that we can return the geom_id in the same way as in for blazertscene, otherwise this is not really transparent.

Is your feature request related to a problem? Please describe.
Switching from a sphere primitive to an ellipsoid would greatly improve flexibility of the framework. Should be useful for scientific applications, because spherical bodies are usually only approximations.

Describe a possible solution.
An ellipsoid can be transformed to a sphere such that the existing intersection algorithms and so are still useful. The only thing that would need to be changed is a coordinate transformation before the intersection algorithm and the inverse transformation before setting the intersection points and normals.

Furhtermore, the test cases would need to be adapted due to an API change for the sphere. Alternatively, there could be a overload/type alias/... of some kind to provide a sphere with radius R in terms of an ellipsoid. C

Describe alternatives you've considered
Leave the Sphere primitive exactly the way it is and create a new primitive.

We should discuss which approach we are going to use.

The first approach would be API breaking, which in my opinion is ok at this stage of the project.
The second approach would not be API breaking but would already clutter the code base with unnecessary duplication or similar issues.