|
 |
"Trevor G Quayle" <Tin### [at] hotmail com> wrote:
> > Nice, this is really starting to come together, looking good. What's the parse
> > time for the grime algorithm per head mesh here?
>
> I am using very low testing settings so I can get quick results, but parsing
> depends on the sample resolution, and number of normals traced. On my home
> machine, with res set to 400, number of trces set to 32, this parsed in
> ~30seconds, including ~7seconds to load the mesh (~35MB). Rendering is another
> 40secs on top of that, mostly because of all the intersections for each
> grime-pixel. I've been think about a way to try to make a procedural texture
> out of it rather than the current method.
>
> -tgq
I figured out a way to convert my number to a pigment: save to an array, export
as .df3 file and read in as density_file pattern. This speeds it up
considerably on the render time. The average render time for the heads shown
with a ersoltuion setting of 400 was about 30sec compared to over 60sec
previously, with the majority (26s) being parse time. I gave me the offshoot
ability of using the interpolate function for density files. The 2nd image ins
with interpolate 1, and the 3rd is with interpolate 2. The interpolate 2 seems
to cause banding at the transition points. Interpolate 1 is ok (there are
issues at smaller resolutions though.
One thing I noticed is that with interpolate 1 there is a distinct shift down
and to the left. Is there a bias in the internal interpolate function? This is
something that I have noticed before with interpolate.
-tgq
Post a reply to this message
Attachments:
Download 'trace-4.jpg' (135 KB)
Preview of image 'trace-4.jpg'
|
|
