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 <pildano...@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. <aure...@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 <d...@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@blender.org > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers