All Projects

Height=36084

[640×360, AA 0.3]
Width=640
Height=36084
Antialias=On
Antialias_Threshold=0.3

should be:

[640×360, AA 0.3]
Width=640
Height=360
Antialias=On
Antialias_Threshold=0.3

see my post titled: “area light and radiosity problem?” in povray.binary.images [Edit - copied that post’s text here - clipka]

wondering about what’s going on here with this series of images. the radiosity and area light settings are unchanged from image to image, and all I did was radiosity on/off and area_light on/off (btw: using rad_def “Normal” settings)

the 1st image is radiosity only, the 2nd is area light only, and the 3rd combines them:

what’s up with blotches? change #5819/5820 (octree) or maybe something still with area lights?

I’ve had a series of what appear to be a hang up’s. They passed parse, reported some stats and issued the Rendering... message and opened the preview window, but never progressed. They continued to accumulate cpu time until I eventually had to kill -9, softer didn’t work.

I’ve been dismissing them up until now wanted to speak up because I finally got this crash:

29623 Segmentation fault

Here’s some observed behaviors:

In my scene I have a Round_Box_Union with /just/ a pigment that rendered fine, but when I added a wood texture from the distribution includes, it hung up after I tried to transform the texture in any way. Tried other distribution textures ... same thing.

I spent time going through different scenarios looking for a common cause (thinking I’m doing something wrong). Eventually I arrived at the point that I killed a hung render, and restarted the same render with no changes. Sometimes it would render, sometimes not ... I finally got the above mentioned Round_Box_Union to behave with a simple reflective texture, and the rounding parameter had to be above 0.1 ... I settled at 0.125. OK by now you’re thinking WTF right?

No more problems until I accidentally (typo) put an additional light_source at the same location as another light_source. It also hung sometimes, and rendered fine sometimes after a kill ... no SDL changes.

Now I can’t tell you exactly what I was doing when the seg fault happened, but I /do/ know I just restarted the render with no changes. I’m starting to think there’s some kind of instability happening here. I realize that I’m probably the only team member spending any real time with the application, so none of you probably haven’t noticed anything suspicious.

Any comments ... ideas ... suggestions?

~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.

parser fails to report when an illegal map_type is used. For example map_type 10 and map_type 100 doesn’t produce an error

Certain types of errors are being reported twice. For example:

Parse Error: Expected ‘numeric expression’, } found instead
Parse Error: Expected ‘object’, undeclared identifier ‘foo’

The first error was a user typo when not enough parameters were specified, and the later when calling a yet to be declared object.

During investigation it was also discovered that improperly formed scale statements also produced the double error report: <scale 1,0.5,1>

Verified on linux and windows platforms.

povray +Imesh_camera.pov +Omesh_camera.png +FN +W800 +H600 produces a “Failed to parse command-line option” error. when I rename my pov source file to ess_mesh_camera.pov it runs fine. seems to be pointing to a clash with the +im option. i also had another file that renaming it got me going.

couple of observations:

if no photons are gathered (hey it happens ... my typo) when attempting to save a photon map the warning message just indicates that it couldn’t save the map, maybe the message could be enhanced to say something like: No photons were gathered so no map information was saved. At first I thought something had changed in my I/O restrictions (I’m writing to an image directory not current or work directory)

when reading a previously saved photon map there is no indication that it was read in other than the end stats showing a small amount of photon time. I don’t recall but didn’t v3.6 indicate that the a previously saved map was being used? Just for the heck of it I moved the map file aside and it did prove to me that it was indeed being input. Some sort of message at the time the file is read in might be helpful.

I got a 29023 Segmentation fault ... but it was NOT repeatable. I reran the render job repeatedly and it displayed appropriate error message. I had renamed a texture identifier but missed an occurrence inside texture_map.

FYI: I did a build off the depot last evening.(21:13)

the quick_color feature doesn’t work when +qN or Quality=N is set to 5 or below

no warning is issued when an object/primitive has no pigment type given

There is a confirmed bug when writing jpg file format with the current linux build (beta39). when specifying +fj output format the following error occurs:

JPEG parameter struct mismatch: library thinks size is 372, caller
expects 376
JPEG parameter struct mismatch: library thinks size is 372, caller
expects 376
Render failed

this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32 bit version) as openSuSe 11.2 64-bit reports no problem

there has been a proposed fix to ~smp/source/base/image/jpeg.cpp that appears to work, however it requires some additional work to make it a platform (linux) and compiler (gcc) specific fix.

value is erroneously clipped to the range 0..1 before being displayed

Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.

I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.

The #switch directive isn’t parsing correctly. In the following construct NO warning or error is generated:

#switch (RF)

case (0)
	rotate z*355
#break
case (144)
	rotate z*7.5
#break
case (216)
	rotate z*5
#break

#end

RF is a variable passed to the macro in which this construct resides. The first ‘case’ action IS executed, but none of the others are on successive calls to the macro. If I properly add ‘#’ to the second case the 1st and 2nd condition are executed but not the last. If ‘#’ is REMOVED from any of the break directives an error is generated and parsing halts.

woodmaps.inc depends on colors.inc, more specifically the definition of the color “Clear” perhaps a #ifndef colors.inc belongs in woodmaps.inc or probably more correctly changing the call of “Clear” to rgbf 1

When using cutaway_textures the differenced part traces black. Simple scene file attached.

Develop MediWiki extension to extract documentation sets from the POV-Wiki.

Recruit version 3.7 documentation editors from the users community.

After a recent update on the POV-Wiki the GuMax skin doesn’t recognize MediaWiki:Common.css entries.

In unix distribution these scripts

• allscene.sh
• allanim.sh
• porfolio.sh

have the variable VERSION set to 3.6