-
http://rapidshare.com/files/330803463/firetest3.blend.tar.lzma.html
the test file.
2010-01-05 18:09:17 UTC by mohanohi
-
while rendering on 25th frame it takes about 700 mb of memory and slows down.
2010-01-05 18:00:31 UTC by nobody
-
Mainly this happens as a user error. If I accidentally side my fingers over the touch pad when Piqsl is the focused application, it will zoom in so far that it locks up completely, with the spinning colour wheel of Idle. Sometime it does eventually come back, but it can be several minutes. This happens even if there is only one image in the catalog. I also tried with the + key, and after 5...
2010-01-04 11:24:32 UTC by capramambrica
-
One thing I noticed was that the aqsisrc file is generated with a leading colon (i.e., [":/usr/local/share/..., rather than ["/usr/local/.."). After changing this, aqsis seemed to be better able to find the shaders in the path, although it did not automatically build the "*.sl" files into "*.slx". After doing this manually, aqsis was able to run the scene.
2009-12-17 06:17:37 UTC by bfulgham
-
This is very likely because aqsis_tex isn't memory efficient when downsampling: it simply reads the entire image into memory before doing any operations. Fixing this problem is probably a task for after the OIIO texture library integration. (OIIO may even have memory efficient downsampling already in which case we won't need to do anything!)
2009-12-07 07:13:10 UTC by c42f
-
This is due to the way that MacOSX handles the shader paths in it's aqsisrc. It seems that the "defaultshaderpath" is setup using the %AQSISHOME% environment variable, and in aqsisrc.in.cmake, the shaderpath is set to [".:@:${SHADERPATH}"] and ${SHADERPATH} is only set in a MacOSX build, and is set to the same string as the ${DEFAULT_SHADERPATH}.
I'm guessing the reason for the ${SHADERPATH}...
2009-12-01 23:26:30 UTC by pgregory
-
$ aqsis --version
: aqsis version 1.6.0 (revision 0)
: compiled Oct 11 2009 13:19:03
As discussed on IRC 02/12/09.
2009-12-01 23:19:40 UTC by nobody
-
The problem is that the default class for "st" is "varying" which in the case of PointsPolygons requires a single value per geometric vertex (i.e. for each value of "P"), whereas "facevarying" requires a value per polygon vertex (i.e. the sum of the values in the nvertices array).
Specifying the type for "st" fully, i.e. "facevarying float[2] st" solves the problem and makes the first set of...
2009-11-29 20:49:35 UTC by pgregory
-
It seem using st syntax instead s and t, return different results. For example, using
"st" [
0.5 0.0
0.0 0.0
0.0 0.5
0.5 0.5
1.0 0.0
0.5 0.0
0.5 0.5
1.0 0.5
0.5 0.5
0.0 0.5
0.0 1.0
0.5 1.0
1.0 0.5
0.5 0.5
0.5 1.0
1.0 1.0
]
instead
"facevarying float s"
[
0.5 0.0 0.0 0.5
1.0 0.5 0.5 1.0
0.5 0.0 0.0 0.5
1.0 0.5 0.5 1.0
]
"facevarying...
2009-11-29 18:03:44 UTC by nobody
-
c42f pushed 1 commit(s) to refs/heads/master in the aqsis Git repository of the Aqsis Renderer project.
2009-11-27 22:08:16 UTC by c42f
