All Projects

Whenever some object is to be periodically repeated in some kind of grid, you can achieve this with macros, but it
a) wastes a lot of resources

 even if object references are implemented in the future, wrapper with its own transformation matrix still takes space and bookkeeping

b) is not infinite

 annoying when making infinite planar tiling with arbitrary objects
 like an approximate water surface or tiling with real bricks
 or anything that needs to extend to horizon

c) is not optimized for periodicity

I think it can be very efficiently implemented as an object that takes a finite object argument (like CSG functions) and can be periodic in either 1D,2D or (possibly dangeorous?) 3D with specified period. In each dimension, the number of repetitions can be any integer or even infinity (or max_int). Something like
periodicity <2,2,Infinity> 2 copies in 1 direction, 2 in the other, infinite in the third
grid_separation <1,2,2> 1 unit size in first direction, 2 unit sizes in the other two

All the code needs to do is raytrace in the current unit cell and if the ray passes uninterrupted, pass it through the neighbouring unit cell (which means trace a translated ray through the same object). The object itself would just feel an additional clipping box, everything else would work seamlessly.

In case of infinite column of transparent object, max_trace stops the infinite loop anyway.

This is just a suggestion, I realize this is more of a long-term change but it is quite easy to implement and would simplify a large number of projects.

The sphere_sweep renders well when specified directly, but when it is scaled, its bounding box is calculated incorrectly, which clips the object so it almost disappears.

The effect is present for all three types of splines.

I’m attaching a test scene and the rendering result. The saving of the object with #declare has no effect, I just wanted to show both transformed and untransformed version.

I don’t think this issue is related to other artifacts occuring with sphere_sweep, as it is obviously an issue of the internal bounding box.

If a blob is intersected by something else, the composite object has incorrect refractions if it is too small (in absolute units). Having the same object constructed without a blob, the errors happen at much smaller scales. The errors don’t affect solid objects, just refractions.

An example shows a half-sphere, constructed as CSG sphere + plane, and identical half-pshere, constructed as CSG blob + plane. When the scale of the entire construction is changed, the refractions disappear first for the blob, and at 100x times smaller scale, also for the sphere. The right side shows the solid version, showing that the surface intersection test is ok, it’s just the refraction that fails.

The problem is not present when looking from the curved side (the blob side). So the ray that hits the blob, gets refracted correctly, but the ray that hits the intersecting plane first, and should then refract in the blob from the inside, doesn’t work. If in attached sphere, you exchange -y with y in clipping planes, everything is ok.

The scale when this happens is not very small - blobs of radius 0.02 already fail (noticed because in 1=1metre scale, blob raindrops on a glass plate didn’t have intersections when looking from the back).

Examples are named by factor=9,0.9,0.09,0.009 and you can see first the blob (top) refraction gets smaller and disappears, then later the bottom (sphere) also gets the same problem.

A low priority thought for the future: isosurface now only allows contained_by to be a sphere or a box. It would be more intuitive to allow the same objects that are allowed in clipped_by and bounded_by (although it probably needs to be finite). It would enable allow much faster rendering in many cases:

1) There are a lot of cases when the sphere or a box are very bad in bounding - if an object has a hole, a torus may be better, and in many cases, cylindrical bounding would help a lot.
2) Sometimes, having a too large contained_by object includes far-away parts of the iso-function, and expose large gradients that you want to avoid. If a bounding object is better, you can decrease the max_gradient and speed up the render.
3) The isosurface is usually much more expensive to calculate than any normal bounding object, so it’s an improvement even if the intesection test is not as fast as bounding box.
4) A typical case: if you use texture-like functions to make the surface realistically rough, you know almost exactly what the bounding object is - it can be the original unmodified object.
5) For isosurface terrains, a preprocessing macro could create a rough mesh-like bounding object to contain the “mountains”, thus making everything faster.
6) In case you want clipping, having the contained_by set to the same object probably avoits calculating too many intersections.

The main modification is probably that the intersections of bounding objects can be split into more than one interval - but it’s probably worth it, the isosurfaces are usually a speed bottleneck.

While familiarizing myself with the code, I found some small changes in the solve_cubic function that lead to a significant speedup.

In my experience, “pow” is by far the slowest function in math.h and replacing it with simpler functions usually makes a tremendous impact on the speed (it’s an order of magnitude slower than sqrt/exp/cbrt/log).

solve_cubic has a “pow” function that can be replaced by cbrt (cubic root), which is standard in ISO-C99 and should be available on all systems. Separate benchmarks of solve_cubic function show this change almost doubles the speed and does not lower the accuracy. As solve_cubic is part of the solution of quartic equation, this improves the speed for many primitives. Testing with a scene containing many torus intersection tests (attached below) I still observed almost 10% speedup (Intel, 4 threads, 2 hyperthreaded cores, antialiasing on, 600×600: from 91 to 84 seconds). And this is for a torus, where a lot of time is spent in the solve_quartic and cubic solver is only called once! Similar speedup should be expected for prism, ovus, sor and blob.

I do believe the cubic solver can be done without trigonometry, but that would mean changing the algorithm, introducing new bugs and requiring a lot of testing. However, the trigonometric evaluation can still be simplified (3% speedup in full torus benchmark).

These changes don’t affect the algorithm at all, they are mathematically identical to the existing code, so the changes can be applied immediately. I also included other changes just as suggestions. Every change is commented and marked with [SC 2.2013].

This sadly does not speedup the sturm solver, which uses bisection and regula-falsi and looks very optimized already.

The test scene I used has a lot of torus intersections from various directions (shadow rays, main rays, transmitted rays).

the pigment {} and normals {} sections allow spatial variation of color, transparency and normal map. On the other hand, the specular parameter is a fixed scalar. This removes many possibilities. For instance, specularity could vary in space (speckles of oil or water on a surface, worn-out finish, having specularity reduce where the pigment transparency increases) and have color components. With current settings, the light’s color is simply multiplied by the scalar specified by “specular”, whereas multiplying each component with different color could create diverse effects (the “metallic” keyword already acts similar to duplicating the specular color from the pigment). The syntax could be exactly the same as for the pigment (all the patterns, color maps, image maps and functions would apply, allowing reuse of most of the code).

The effect can now be partially faked by having patterned textures, but it requires a very complex code and the lack of layering of patterned textures makes it difficult to vary the specularity and pigment separately.

In a similar way, roughness and brilliance could also vary in space.

Doing the same for varying reflectivity would be more difficult, as it has angular dependence and possibilty of Fresnel calculation, but it could at least be a full color instead of a simple scalar multiplier. For instance, having a blue surface that reflects only red component of the light should not be impossible.

I think at least part of this functionality actually makes the scene description language more uniform and self-consistent.

When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal
are first displayed like this:
Rendered 126202 of 360000 pixels (35%)
Then on the second stage the output text becomes shorter and you see
Rendered 25344 of 360000 pixels (7%)%)
The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.

I’m running
Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu)
compiled for the Arch Linux package.