Bug

[Loïc Fejoz]

Hi,

I have a bug with following shader :

--------------------------
int material(vec3 p,int groups)
{
  if ( in_group(0) ) {
    if (sqrt(exp2(p.x)+exp2(p.y)) < 1/cos(atan(p.x, p.y))) {
        return 0;
    }
  }
  return -1;
}
--------------------------

I obtains following message:
--------------------------
[module::order]    done in 00:00:00.                     <OK>
[module::travel]   ERROR(no path in first layer??)
[module::skirt]    **ASSERT FAILED** first_tool > -1, file ..\..\..\SLEFEBVR\PRO
JECTS\ICESL\icesl-devel\trunk\modules\skirt\Skirt.cpp, line 48
--------------------------

The script is:
--------------------------
emit(translate(0.5, 0.5, 0.5) * box(1)  , 0 )

load_material_shader('tuto_shader1.sh')

set_group_color(1, 0.3,1.0,0.3);
set_group_color(0, 0.3,0.3,1.0);
--------------------------

PS : I have tried to add conditions for p.x and p.y not to be null at the same time but it does not change the result.

regards,
Loïc

[sylefeb]

Hi Loic,

Usually this happens because the first layer does not contain any path; that is, your shader returns -1 everywhere when the slice is computed. A simpler way to test is to return 0 or 1, instead of carving. This way you can more easily test your formula.

But the issue here is not the shader. It is important to realize that on screen display has infinite resolution, in the sense that when you zoom in on the object, the formula is computed every pixel. Therefore, it seems fine on screen.

During slicing, a fixed resolution is used (0.05 mm per pixel) ; but your cube here is only 1 mm wide. Because of that, aliasing issues occur and the shape described by the formula is not properly sampled.

If you switch to a large cube (10 mm), it will be fine.

Also keep in mind that the 'p' coordinate is mapped within [0,1] in the bounding box of the object (normalized coordinates). You can get its millimeter version (absolute coordinates in millimeters) by calling 'mm(p)'

[Loïc Fejoz]

Ok I understand. Still have to handle the assertion properly and not closing the windows... :-D

Again thanks for the tip of using one color first for debugging then carved.

I also wasn't aware of the mm(p) stuff and wandering why changing the distance and size was not changing as I thought but RTFM again! ;-)