The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.


FS#196 - More SSLT Caveats

Attached to Project: POV-Ray
Opened by Jim Holsenback (jholsenback) - Tuesday, 01 March 2011, 20:40 GMT
Last edited by William F Pokorny (wfpokorny) - Saturday, 10 December 2016, 15:06 GMT
Task Type Definite Bug
Category Backend → Subsurface Scattering
Status Tracked on GitHub
Assigned To Christoph Lipka (clipka)
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 RC3
Due in Version Future release
Due Date Undecided
Percent Complete 90%
Votes 0
Private No


when a prism is differenced with a primitive (cylinder in this case) if sslt is used it causes a seq fault. Reference distribution file logo.inc and the Povray_Logo_Prism definition.

This task depends upon

Comment by Jim Holsenback (jholsenback) - Wednesday, 02 March 2011, 12:39 GMT

sslt also doesn't appear to work with "text" objects ... maybe that's my foo or is it just not a happening thing?

clipka: Am I wasting my time cataloging these issues or are they already known to you?
Should these issues be noted in sslt documentation?

Comment by Christoph Lipka (clipka) - Thursday, 03 March 2011, 00:26 GMT

I don't think it makes much sense to publish a catalog of SSLT issues with RC3; the recent changes scheduled for RC4 are pretty fundamental, and I expect behaviour to change drastically, so I'll not look into any issues reported for RC3 anyway (unless confirmed for RC4 as well), and I don't think such a catalog would give any substantial added value to users either.

That said, I'd nonetheless like to ask you to keep an eye on any issues you notice, to check whether any of them are still present in RC4.

Comment by Jim Holsenback (jholsenback) - Thursday, 03 March 2011, 00:33 GMT

I'm running RC4 built out of revision control depot ... these /ARE/ RC4 issues

Comment by Christoph Lipka (clipka) - Thursday, 03 March 2011, 01:05 GMT

Well, thanks for adding this pretty vital piece of information now :-)

Comment by Christoph Lipka (clipka) - Thursday, 03 March 2011, 01:38 GMT

Can't confirm the symptoms you're seeing here (Win x64, Intel core i7); both the Povray_Logo_Prism and a test text render fine with SSLT; can you post the exact scenes you were using?

Comment by Jim Holsenback (jholsenback) - Thursday, 03 March 2011, 12:30 GMT

OK in the process of stripping down my scene I got this error that concerns me:

XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"

    after 114 requests (114 known processed) with 0 events remaining.

povray: /usr/include/boost/flyweight/refcounted.hpp:70: boost::flyweights::detail::refcounted_value<Value, Key>::~refcounted_value() [with Value = boost::flyweights::detail::regular_key_value<double, pov::SubsurfaceInterior::PrecomputedReducedAlbedo>::rep_type, Key = double]: Assertion `count()⇐1' failed.

this was /NOT/ repeatable I have mainly been getting different numbered seg faults. the render completes if I either comment out the prism difference /OR/ the rotate x*90 in my call to Povray_Logo_Prism /OR/ the subsurface {} keyword in the globals block

the FIRST TWO (diff and rotate) are OK when the subsurface keyword in globals block is commented out

attached is scene I've been working with

   work.zip (2.1 KiB)
Comment by Christoph Lipka (clipka) - Saturday, 05 March 2011, 00:35 GMT

I'm still not seeing anything unusual on my Windows machine, so the segfaults are rather obscure to me. Not so with the fatal IO error though, so my hope is that it's somehow related; can you please try recompiling with the following code modifications in lighting/subsurface.h; please replace all

  #if BOOST_VERSION >= 103800


  #if 0

You should find three occurrences, in lines 99, 108 and 132 respectively. If that cures the segfaults, it's a clear indicator that the boost flyweights don't work properly (or that I used them wrong).

Comment by Jim Holsenback (jholsenback) - Saturday, 05 March 2011, 11:33 GMT

nope ... still a problem as before. the scene parses fine and shows the preview window, progresses about halfway through the render then throws the segmentation faults until I comment out the subsurface statement in either the objects finish block, the globals block, or the when I comment out the difference object with the prism in the Povray_Logo_Prism def:

difference {

    prism {-0.9999, 0.9999, 4, <-1,2>, <1,2>, <0,-4>, <-1,2> rotate -90*x}
    //cylinder {-z, z, 1.4 scale <1,0.9,1.1> translate 1.9*y}
Comment by Jim Holsenback (jholsenback) - Saturday, 05 March 2011, 13:16 GMT

This is really bugging me that we've not been able to find something to fix this. I'm fairly sure of my methodology and that something is indeed not right. Maybe it's not related to subsurface, but just another way that the problem manifests itself. For a while now I had strange behavior. For example .. I've had occasions when my scene file would parse, and the preview (sdl enabled) would pop up but wouldn't show any further progress (either in the preview or on the command line). I'd have to kill -9 then restart the job (without any scene file changes) and things were ok fine. BTW: just in case I was being impatient I left it once over night to find no progress in the morning.

OK I've not for sure eliminated my hardware (memory problem maybe), but I also engage in other memory intensive activities ... surely I'd see problems elsewhere, I know that's NOT exactly a technically sound assumption on my part.

I'm going out on a limb here ... mind you this this strictly gut feel here, but my problems started to surface about the time that lseek64 was the hot topic ... well I've got my suspicions that the build process for unix /might/ also be a contributing factor.

Comment by Jim Holsenback (jholsenback) - Sunday, 06 March 2011, 14:52 GMT

I just discovered that povray is leaving behind a .pov-state file after it seq faults ... would that be useful in trying to figure out what's going on. I'll wait to attach just in case it's of no use

Comment by Jim Holsenback (jholsenback) - Monday, 14 March 2011, 02:34 GMT

I pulled the RC3 linux source from the beta test page (did a build) and the scene file that I attached earlier in this thread worked just find WITHOUT the seq faults. The ONLY thing that I did was change the subsurface line in earlier included attachment back to RC3 format. The reason I tried this was that after trying Jeromes' ply2pov converter NONE of those file would render without a seq fault (ok fine with sslt disabled). I guess that verifies my setup (libs, build process and such). Before pulling the RC3 source from the beta page I removed the smp tree from my perforce workspace and did a resync (just in case there was corruption) without any joy. also the converted ply2pov files now work fine too.

Comment by Jim Holsenback (jholsenback) - Wednesday, 16 March 2011, 11:48 GMT

after recompiling RC4 bits with debug mode enabled (–enable-debug configure option) then running:

gdb povray
run /users/ash/POV-Ray/Source/Work.ini

produced the attached debug information

btw: added ovus object to the mix from further testing

Comment by Jim Holsenback (jholsenback) - Friday, 18 March 2011, 09:52 GMT

with sslt enabled a diffuse finish attribute set to 0 the following error occurs:
povray: render/trace.cpp:3549: void pov::Trace::ComputeDiffuseContribution(const pov::Intersection&, const pov::Vector3d&, const pov::Vector3d&, const pov::Vector3d&, const pov::Vector3d&, double&, double, double, double): Assertion (sd >= 0.0) && (sd ⇐ 1.7976931348623157e+308) failed

Comment by Jim Holsenback (jholsenback) - Saturday, 19 March 2011, 20:08 GMT

all the issues EXCEPT the original prism problem have been addressed with change #5425

Comment by Christoph Lipka (clipka) - Sunday, 20 March 2011, 02:19 GMT

Regarding the failed assertion when diffuse finish attribute is zero, this is essentially the same problem that also appears with zero pigments; I think it makes sense to add this to the docs as a known caveat.

Comment by Christoph Lipka (clipka) - Monday, 05 December 2011, 21:01 GMT

Jim, do you have any updates on this issue?

Comment by Jim Holsenback (jholsenback) - Monday, 05 December 2011, 23:16 GMT

haven't noticed any issue's that are different from those already mentioned in the subsurface section of the docs

Comment by Jim Holsenback (jholsenback) - Friday, 24 February 2012, 16:02 GMT

change #5614 seems to have also fixed sslt with the prism and text objects that started this report

Comment by William F Pokorny (wfpokorny) - Saturday, 10 December 2016, 15:06 GMT
  • Field changed: Status (Requires testing → Tracked on GitHub)

Now tracked on github as issue #174.