Consider me a little lost concerning the new version beta. Been a month 
since I gave the newsgroups a look and just discovered this beta testing was 
going on.

I was trying the larger bitmaps renders for the Insert Menu and noticed 
someplace in Shapes.pov getting bounding boxes removed; turned out to be the 
three parametric objects. Just thought I would point this out if something 
isn't right about that, whoever might know what's going on with that.

Also, while I'm here, I've seen that the isosurfaces (again, about menu 
images) for waveforms is still problematic. I had tweaked on that some time 
ago and thought it was rendering those okay, but now I realize it is still 
rendering those only partially. In other words, the tops tend to be missing, 
incomplete, looking broken. Hopefully you'll know what I'm talking about.

Bob Hughes

P.S.

I'm amazed at the changes taking place. Like the new way of showing stats 
and display of renderings in chunks(?). Seems you're all making plenty of 
progress while I sit on the sidelines watching from afar.

P.S.S.

Really appreciate that SSE2 that does benchmark.pov in half the time! Wow... 
Now if I'd just get back to using POV-Ray. *sigh*

Post a reply to this message

Bob Hughes <bob### [at] charternet> wrote:
> I'm amazed at the changes taking place. Like the new way of showing stats 
> and display of renderings in chunks(?).

  Rendering in squares is a way to ensure load balance between threads
and also to try to minimize the overhead caused by antialiasing (although
larger squares would do a better job at this; otoh they have a larger risk
of unbalanced load).

-- 
                                                          - Warp

Post a reply to this message

Bob Hughes wrote:
> I was trying the larger bitmaps renders for the Insert Menu and noticed 
> someplace in Shapes.pov getting bounding boxes removed; turned out to be the 
> three parametric objects. Just thought I would point this out if something 
> isn't right about that, whoever might know what's going on with that.

This is normal; it also happens with v3.6.

> Also, while I'm here, I've seen that the isosurfaces (again, about menu 
> images) for waveforms is still problematic. I had tweaked on that some time 
> ago and thought it was rendering those okay, but now I realize it is still 
> rendering those only partially. In other words, the tops tend to be missing, 
> incomplete, looking broken. Hopefully you'll know what I'm talking about.

Can you provide an example scene ?

-- Chris

Post a reply to this message

"Chris Cason" <nos### [at] deletethispovrayorg> wrote in message 
news:427c0fd7@news.povray.org...
> Bob Hughes wrote:
>> someplace in Shapes.pov getting bounding boxes removed; turned out to be 
>> the
>> three parametric objects.
>
> This is normal; it also happens with v3.6.

Ahhh, okay, parametric isn't something I ever use. Just wanted to be sure 
something wasn't going wrong with it anyway.

>> Also, while I'm here, I've seen that the isosurfaces (again, about menu
>> images) for waveforms is still problematic.
>
> Can you provide an example scene ?

The file  Insert Menu\attributes.pov  and then using:

  #declare Typ=1;     // waveform

 is the actual one I'm talking about. Rendering changes (for me here, 
anyhow) for different resolutions, so you'll need to check a couple 
different image sizes probably. It varies a great deal, from what I've seen.

Watch for pieces missing from the tops, jaggedness, and such. Should be 
smooth representations of the five waveforms:
ramp_wave; triangle_wave; scallop_wave; sine_wave; poly_wave.

Note that the max_gradient numbers for each was the part tweaked to try and 
prevent any reports in the message stream of possible changes for 
improvement for the isosurface max_gradient, which it tends to do otherwise 
as you well know. That reminds me, the Render Menu Bitmaps doesn't do the 
message stream as it used to, guessing you realize that, but not sure you 
do. In 3.6 is only reported progress by a count, whereas 3.7 is showing full 
stats for each and every one.

Might be easier to use the following excerpt of SDL from that file.

// waveforms graphic
// command line suggested in the attributes.pov, so you can use that.
//cmd: -w120 -h48 +a0.1 +am2 -j +r3

#declare Cnt=0;

#while (Cnt < 5)

  #local fn_grad=
  function {
    pigment {
      gradient x
      color_map { [0 rgb 0][1 rgb 1] }
      #switch (Cnt)
        #case (1)
          triangle_wave
          #break
        #case (2)
          scallop_wave
          #break
        #case (3)
          sine_wave
          #break
        #case (4)
          poly_wave 2
          #break
        #else
          ramp_wave
      #end

      scale 1.2

    }
  }

  #declare Tex1=
  texture {
    pigment {
      function { fn_grad(x, y, z).gray }
      color_map { [0 rgb 0][1 rgb 1] }
    }
    finish { ambient 0.2 specular 0.4 }
  }

  object {
    isosurface {
      function { z-fn_grad(x, y, 0).gray*0.5 }

      max_gradient
      #switch (Cnt)
        #case (0) 1000 #break
        #case (1) 0.4 #break
        #case (2) 0.4 #break
        #case (3) 0.4 #break
        #case (4) 975 #break
      #end
      accuracy 0.001
      contained_by { box { <-0.8, -1.2, -1.2> <0.8, 1.2, 1.2> } }
    }

    texture { Tex1 }
    no_shadow
    translate <-4.0+Cnt*2, 0, 0>
  }

  #undef fn_grad

  #declare Cnt=Cnt+1;
#end

Post a reply to this message

/* here's a whole renderable scene */
// waveforms graphic

// command line suggested in the attributes.pov, so you can use that.
//cmd: -w120 -h48 +a0.1 +am2 -j +r3

global_settings {
  assumed_gamma 1
  max_trace_level 5
}

light_source {
  <1.5, 2.5, 2.5>*10000
  color rgb 1.0
}

camera {
    location    <0, 20, 7.5>*4      // waveform
  direction   y
  sky         z
  up          z
  right       (120/48)*x
  look_at     <0, 0, -0.1>
  angle       7
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [1.0 rgb <0.2,0.2,0.8>]
    }
  }
}

plane
{
  z, -1
  texture
  {
    pigment { color rgb 1 }
    finish {
      diffuse 0.7
      specular 0.4
      roughness 0.01

      reflection { 0.5 , 1.0
        fresnel on
        metallic 0.8
      }
      conserve_energy
    }
  }
}

#declare Cnt=0;

#while (Cnt < 5)

 #local fn_grad=
 function {
   pigment {
     gradient x
     color_map { [0 rgb 0][1 rgb 1] }
     #switch (Cnt)
       #case (1)
         triangle_wave
         #break
       #case (2)
         scallop_wave
         #break
       #case (3)
         sine_wave
         #break
       #case (4)
         poly_wave 2
         #break
       #else
         ramp_wave
     #end

     scale 1.2

   }
 }

 #declare Tex1=
 texture {
   pigment {
     function { fn_grad(x, y, z).gray }
     color_map { [0 rgb 0][1 rgb 1] }
   }
   finish { ambient 0.2 specular 0.4 }
 }

 object {
   isosurface {
     function { z-fn_grad(x, y, 0).gray*0.5 }

     max_gradient
     #switch (Cnt)
       #case (0) 1000 #break
       #case (1) 0.4 #break
       #case (2) 0.4 #break
       #case (3) 0.4 #break
       #case (4) 975 #break
     #end
     accuracy 0.001
     contained_by { box { <-0.8, -1.2, -1.2> <0.8, 1.2, 1.2> } }
   }

   texture { Tex1 }
   no_shadow
   translate <-4.0+Cnt*2, 0, 0>
 }

 #undef fn_grad

 #declare Cnt=Cnt+1;
#end

Post a reply to this message

well, this is an interesting one.

the bug itself isn't in the new code; it is just being highlighted by the
block rendering we do. it even happens in single-thread mode, which means it
must be related to the horizontal extent of a render since that's the only
change in the order of pixels between the classic rendering and the new block
rendering when there is only one thread. And indeed if I set the block size
to 1x1 or to the render width, the results between 3.6 and 3.7 are identical.

The code must have some dependancy on the order in which parts of the surface
are probed. Take this scene for example:

//---------------------------------------------------------------------------

global_settings
{
  assumed_gamma 2.2
  max_trace_level 6
}

light_source { <-1, 1, -1> color rgb 1.0*0.5 shadowless }
light_source { <0, 1, 1> color rgb 1.0*0.5 shadowless }
light_source { <1, 1, -1> color rgb 1.0*0.5 shadowless }
light_source { <0, 1, -5> color rgb 0.75 shadowless }
light_source { <0, -1, -5> color rgb 0.75 shadowless }

camera {
  location    <0, 1, -3>
  look_at     <0, 0, 0>
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [1.0 rgb <0.2,0.2,0.8>]
    }
  }
}

plane
{
  y, -1.25
  pigment { colour rgbft <0,1,0,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

plane
{
  x, -1.25
  pigment { colour rgbft <0,0,1,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

plane
{
  x, 1.25
  pigment { colour rgbft <1,0,0,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

plane
{
  y, 1.25
  pigment { colour rgbft <0,1,1,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

#local fn_grad=
function {
 pigment {
   gradient x
   color_map { [0 rgb 0][1 rgb 1] }
   sine_wave
   scale 1.2
 }
}

object {
 isosurface {
   function { z-fn_grad(x, y, 0).gray*0.5 }
   max_gradient 0.4
   accuracy 0.001
   contained_by { box { <-1,-2,-1> <1,2,1> } }
   rotate <90,0,180>
   translate z*-1
   scale 0.75
 }
 pigment { colour rgb 1 }
}

#if (1)
plane
{
  z, 1.6
  pigment { colour rgbft <0,0,0,0,0> }
  finish { reflection { 1 } }
  no_reflection
}
#end

//---------------------------------------------------------------------------

If you render it at 320x240, no AA, you will get different results between
3.6 and 3.7. However, if you add

  +sc160 +ec191 +sr76 +er107

to the command-line and render it again you will get identical results - 3.6
will now behave as 3.7 does. To further demonstrate that it's a order issue,
change the #if (1) at the bottom to #if (0) to turn off the reflection behind
the object, and render with the above command-line again. You will see that
the surface renders as expected in both versions.

Hopefully someone with the time will have a look at the existing code in v3.6
and work out what the cause of this is (most likely something very obvious
like a value being stored that depends on the order of calls); for the moment
I have to concentrate on 3.7-specific issues.

thanks for pointing this out,

-- Chris

Post a reply to this message