Right primary rays were brute force sorry,
Moving lights making small & bright lit patches lighting the rest of the
room
is what makes flickering the most prone.
For instance, a slowly moving sun (and camera),
with small light portals (perhaps a punched grid running across windows?)
just as the sun starts to peirce through after high noon, would be a
very tough flicker test.
Still cant get over those numbers for something with (all very wide)
DOF, MB & glossy reflections.
On 02/04/2013 5:47 PM, Sven Constable wrote:
Its not bruce force, its biased. So flickering can be an issue. To see
it, we need a movie that predestines a scenario critical to flickering
with biased renderers.
*From:* softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of *Jason S
*Sent:* Tuesday, April 02, 2013 23:21
*To:* softimage@listproc.autodesk.com
*Subject:* Re: Announcing Redshift - Biased GPU Renderer
I agree that it makes it difficult to spot any flickering with a fast
moving camera,
but it was enough to see that if there was any, that it would be
minimal if there was at any at all..
Especially that brute force was used.. meaning flickering should be a
non-issue anyways no?
We should actually be looking for noise in this case,
and there doesn't seem to be too much of that either..
Would still like to see a slow moving shot with perhaps a moving sun,
using the aproximation methods that is..
but 3min using brute force :o
Thanks for that though!
On 02/04/2013 5:06 PM, Sven Constable wrote:
Appreciated! But the amount of mb and the rapid camera pan in that
movie makes any flicker unnoticable even it was there ;) Could you
render it without mb, just *slow* camera animation and moving lights
so we can see possible flickering (or lack thereof)?
Thanks man,
sven
*From:* softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>
[mailto:softimage-boun...@listproc.autodesk.com] *On Behalf Of
*Octavian Ureche
*Sent:* Tuesday, April 02, 2013 20:37
*To:* softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>
*Subject:* Re: Announcing Redshift - Biased GPU Renderer
Speaking of the wolf....
Was just getting ready to post it.
So here it is:
https://dl.dropbox.com/u/2109634/classroom_dof_moblur_animation_v02.mov
A couple of notes on it though. It had around 3 min / frame (some
frames i saw 2:40 min).
The thing is, i'm using brute force for the primary rays, since i'm
still trying to understand the engine, and
it's the slowest approach of all. Also i doubled the rays since the
still image to make sure it looks neat (someone mentioned noise for
that one), so now it's 1024 rays. Another thing i did was to lower the
screen radius to 8 on the IPC and raise the samples per pixel to 64.
Kept a pretty low setting on the dof (128 samples), and put a higher
sampling on the moblur (512). That's why, if you look frame by frame,
you will see some noise in the dof.
All in all, given that, with proper knowledge of the engine and a
different primary ray approach like IC, one could surely take the
rendertime down, i'm still impressed by a noiseless brute force
solution that does dof and moblur in under 3 mins/frame. Oh, and i
have a 3 year old gtx470 with 1 gb vram.
And i just started using redshift yesterday :)
Cheers,
Octav
On Tue, Apr 2, 2013 at 9:23 PM, Tim Leydecker <bauero...@gmx.de
<mailto:bauero...@gmx.de>> wrote:
Hi Octavian,
is an update/sequence render of the (animated) classroom scene
available already?
Would be really interesting how the DOF/MoB and GI play together with
animation
and how long it takes to get the results smooth across frames.
Cheers,
tim
On 01.04.2013 23:37, Octavian Ureche wrote:
yap,
i have some time to kill tomorrow so i'll give it a go.
see know how it turns out
On Tue, Apr 2, 2013 at 12:29 AM, Andreas Bystrom
<andreas.byst...@gmail.com <mailto:andreas.byst...@gmail.com>>wrote:
octavian, could you render a small animation with that exact
setup? with
say a camera move and some animated objects inside the room?
On Tue, Apr 2, 2013 at 8:11 AM, Doeke Wartena
<clankil...@gmail.com <mailto:clankil...@gmail.com>>wrote:
Can someone tell me why so many renderers are CPU based?
And what is the
up and downside apart from speed.
2013/4/1 Len Krenzler <l...@creativecontrol.ca
<mailto:l...@creativecontrol.ca>>
It is a fantastic render engine. That grain can
easily be removed by
a little tweaking and not much more render time.
- Len
On 4/1/2013 12:49 PM, Andres Stephens wrote:
Wow, I got access to the Alpha, and I'm really digging
it also! But I
haven't got a sample scene to benchmark yet. But I
like what you've got
there, and great times!
But.. are you happy with the grain in the image?
Thanks for sharing the image. =)
-Draise
------------------------------
From: okt...@gmail.com <mailto:okt...@gmail.com>
Date: Mon, 1 Apr 2013 19:17:32 +0300
Subject: Re: Announcing Redshift - Biased GPU Renderer
To: softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>
Crossposting and a little OT but i just had to share this.
Took some time today and finally fiddled a bit with
redshift.
1:41 mins on a gtx470 with the old classroom scene (10
min for material
setup, 1 hr to figure out the settings).
Dof and motionblur straight from the renderer.
I really dig it so far.
Cheers,
Octav
PS.and i managed to finish the vray displacement
test scene which i
have to cleanup and share later today.
[image: Inline image 1]
--
_________________________________________________
Len Krenzler - Creative Control Media Productions
Phone: 780.463.3126
www.creativecontrol.ca <http://www.creativecontrol.ca>
- l...@creativecontrol.ca <mailto:l...@creativecontrol.ca>
--
Andreas Byström
Weta Digital
--
visual | stuff
www.okto.ro <http://www.okto.ro>
