[Bf-committers] cycle todo list

Agustin Benavidez agustinbenavidez at gmail.com
Fri Apr 29 13:07:34 CEST 2011


Hi, @Vilem Novak

Regarding to SLG, it has been developed as a test platform for ported GPU
algorithms to be integrated latter in LuxRender, even now SLG is going to be
a more serious effort, is unclear how it is going to driven, or if it will
keep being a test platform. Besides the orientation of SLG is mostly
 towards to physical based rendering, using mainly unbiased techniques and
limited amount of physical shaders.

Cycles as Brecht point out, tries to fit a space between totally
customizable/biased renders like Renderman, and Phiscal based renders like
Lux, SLG and so on.
Brecht has been doing s serious design and developing from
the foundation, SFX capabilities like a powerful network shader system, OSL
shading leguague and other things.

To me SLG could be a complementary effort if it tries to maintain its
position.

Cheers.



2011/4/29 Vilem Novak <pildanovak at post.cz>

> Another question is, why not to take an OpenCL renderer which is allready
> quite usable and go on from it?
> there has been recently a new release of smalluxgpu renderer,
> and in the accompanying forum a wish for direct integration into blender
> was mentioned.
> http://www.luxrender.net/forum/viewtopic.php?f=34&t=5987
>
> for those who are not familiar with slg, here you can see the direct
> interaction between slg and blender in "Livemode":
>
> http://www.youtube.com/watch?v=bSQoJW9ajmU
>
> note that this livemode isn't integrated and has to transport all data to
> the renderer.
> Smalluxgpu is based on Luxrays, a raytracing library supposed to work with
> OpenCL and CUDA, just that the CUDA backend wasn't started/used yet(as far
> as I know), because there was no need for it.
>  SLG was allready tested on various hardware, and because it is OpenCL,
>  you can also run it only on the processor, without GPGPU cards.
> Cheers,
> vilem
>
>
> > ------------ Původní zpráva ------------
> > Od: Aurel W. <aurel.w at gmail.com>
> > Předmět: Re: [Bf-committers] cycle todo list
> > Datum: 29.4.2011 11:49:37
> > ----------------------------------------
> > Hi,
> >
> > before taking this too much off the ground, wouldn't it be better to
> > just stick to OpenCL right from the beginning?
> >
> > I think if this is too much tightened to CUDA from the beginning, we
> > won't see an OpenCL port afterwards.
> >
> > I haven't looked at the architecture of cycles yet and to which degree
> > it's implemented in CUDA, but when it is more, than just a simple
> > raytracing core, as it's done now in luxrender, it would be painful to
> > get OpenCL porting, after a lot of functionality is implemented.
> >
> > aurel
> >
> > On 28 April 2011 22:55, Dan Eicher <dan at trollwerks.org> wrote:
> > > Also...
> > >
> > > This boost-1.44 patch breaks the compile:
> > >
> > >
> >
> https://svn.boost.org/trac/boost/changeset/62245/trunk/boost/detail/sp_typeinfo.hpp
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> >
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list