POV-Ray

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?

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.

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

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

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?

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)

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

with

  #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).

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}
 }

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.

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

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.

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

   debug-info.txt (0.7 KiB)

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

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

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.

Jim, do you have any updates on this issue?

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

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

Now tracked on github as issue #174.