Am 23.02.2011 13:11, schrieb Jim Holsenback:
> no kidding ... why is that with isosurfaces the render times skyrocket
> (besides the obvious isosurface slow downs) ...

Actually it /is/ the obvious isosurface slow downs. SSLT is very 
intersection-test-intensive, and that's exactly where isosurfaces suck.

> should i expect similar performance with updated method?

Yup. Updated stuff includes bugfixes & an easier-to-use syntax, but no 
performance improvements yet.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Yup. Updated stuff includes bugfixes & an easier-to-use syntax, but no
> performance improvements yet.

I've noticed a weird X-pattern on superellipsoid faces with SSLT in RC3, just
wondering if you get the same thing with the new method.

Here's an image that illustrates what I mean - the left superellipsoid has the
X-pattern (like triangular faces with non-planar normals), the right
superellipsoid is the exact same but with no SSLT and using reflection &
transmit instead, but it looks as expected.

So, how does your die scene look using a superellipsoid instead of the
isosurface approximation mesh?

-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

Attachments:
Download 'sslt_embossed_superellipsoid.png' (217 KB)

Preview of image 'sslt_embossed_superellipsoid.png'

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> I've noticed a weird X-pattern on superellipsoid faces with SSLT in RC3, just
> wondering if you get the same thing with the new method.
>
> Here's an image that illustrates what I mean - the left superellipsoid has the
> X-pattern (like triangular faces with non-planar normals), the right
> superellipsoid is the exact same but with no SSLT and using reflection &
> transmit instead, but it looks as expected.

For comparison here's an SSLT box using the same basic setup - no X-pattern in
the box though, just in the superellipsoid...

-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

Attachments:
Download 'sslt_box.png' (284 KB)

Preview of image 'sslt_box.png'

Am 23.02.2011 23:14, schrieb Robert McGregor:
> I've noticed a weird X-pattern on superellipsoid faces with SSLT in RC3, just
> wondering if you get the same thing with the new method.
>
> Here's an image that illustrates what I mean - the left superellipsoid has the
> X-pattern (like triangular faces with non-planar normals), the right
> superellipsoid is the exact same but with no SSLT and using reflection&
> transmit instead, but it looks as expected.

Did you use radiosity for those images? If so, can you try again without 
radiosity?

If it appears only when radiosity is enabled, chances are it will be 
fixed with the next release.

Otherwise there might be some distance threshold hidden in the 
superellipsoid intersection testing code; SSLT is quite sensitive to 
such things, as it needs to shoot rays from just slightly below the 
surface. I know that blobs have such issues, for instance. To really fix 
that, I'd need to do some changes deep in the bowels of POV-Ray - which 
of course is a no-go during release candidate phase.

Post a reply to this message

Am 23.02.2011 23:14, schrieb Robert McGregor:

> So, how does your die scene look using a superellipsoid instead of the
> isosurface approximation mesh?

No such artifacts here, so I'm optimistic that it's something I fixed.

Post a reply to this message

Render time 1 day 3 hours. I guess I quite like it by now...

Post a reply to this message

Attachments:
Download 'ssltdie_2011-02-24.jpg' (147 KB)

Preview of image 'ssltdie_2011-02-24.jpg'

On 23/02/2011 7:03 PM, Stephen wrote:
> On 23/02/2011 6:21 PM, Robert McGregor wrote:
>> Yes, meshes typically render very quickly.
>
> I second that.
>

But.
I'm having problems with the mm_per_unit as it seems to need adjusted 
WRT each mesh. I'm running tests as we speak.

-- 
Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Did you use radiosity for those images? If so, can you try again without
> radiosity?
>
> If it appears only when radiosity is enabled, chances are it will be
> fixed with the next release.

Yes, definitely a radiosity issue! But it only seems to appear in conjunction
with an environment map using emission (jpeg, png, hdr, and exr all produce the
artifacts). Here is a simple scene and a few test renders that will hopefully
point you in the right direction for a fix.

//-----------------------------------------------------------------------------
#declare Use_Radiosity = 1;
#declare Use_HDR       = 1;

global_settings {
   #if (Use_Radiosity) radiosity { } #end
   mm_per_unit 10
}

camera {
   location <3.4, 1.6, -1.6>
   look_at  <0, 0, 0>
   right x*image_width/image_height
   angle 60
   rotate y*30
}

light_source { <-250, 10, 0> rgb 8 }

#if (Use_HDR)
   sphere { 0, 10000 hollow inverse
      //pigment { image_map { jpeg "sky3" interpolate 2 map_type 1 }}
      pigment { image_map { exr "probe_beach" interpolate 2 map_type 1 }}
      finish { ambient 0.25 emission 0.25 diffuse 0 }
      no_image
   }
#end

#declare P_SSLT_Apple = pigment { rgb <0.85, 0.84, 0.53> }
#declare F_SSLT_Apple =
   finish { subsurface { <2.29, 2.39, 1.97>, <0.0030, 0.0034, 0.046> } }
#declare T_SSLT_Apple =
   texture { pigment { P_SSLT_Apple } finish { F_SSLT_Apple } }

superellipsoid { <0.1, 0.1> texture { T_SSLT_Apple } }
//-----------------------------------------------------------------------------

Cheers,
Rob
-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

Attachments:
Download 'sslt_emission_issue.png' (271 KB)

Preview of image 'sslt_emission_issue.png'

Am 24.02.2011 14:44, schrieb Robert McGregor:
>> If it appears only when radiosity is enabled, chances are it will be
>> fixed with the next release.
>
> Yes, definitely a radiosity issue! But it only seems to appear in conjunction
> with an environment map using emission (jpeg, png, hdr, and exr all produce the
> artifacts). Here is a simple scene and a few test renders that will hopefully
> point you in the right direction for a fix.

Thanks, but those artifacts look very familiar to me, from a bug I've 
already eliminated. That, too, did only appear with radiosity, so I'm 
pretty sure your issue has been taken care of.

Post a reply to this message

Am 24.02.2011 12:19, schrieb Stephen:
> I'm having problems with the mm_per_unit as it seems to need adjusted
> WRT each mesh. I'm running tests as we speak.

Nope - I'm pretty sure that's not the case.

There are some issues though that may be related to what you experience; 
for instance, SSLT doesn't yet know about unions, and needs meshes to be 
closed for realism; as your lamp Vicky comes in partial meshes, that's 
currently my best bet for what might cause you trouble.

Post a reply to this message