Alasdair, In my earlier post I mentioned that I was using LUXRENDER at the moment with the new Blender 2.5 Beta ( WIN32 ).
I was suggesting it here because the topic talked of Plugins for FRYRENDER. As LUXRENDER is FREE, open source, I thought it might be of interest to RS programmer types ( :D ) to knockup a plug for Luxrender .. thats all! For anyone interested I did a build today of Latest Blender 2.5 Beta ( nearing official release ). I included the Luxblend plug, all setup to use the Luxrender App. How to's and where to gets are at this thread, 8th message down: http://blenderartists.org/forum/showthread.php?t=192077 Aidan On 20 July 2010 19:40, Alasdair <[email protected]> wrote: > how are you loading it into rs3d and vice versa? > Alasdair > ----- Original Message ----- From: "aidan o driscoll" <[email protected]> > To: <[email protected]> > Sent: Tuesday, July 20, 2010 5:47 PM > Subject: Re: Fryrender plugin support > > >> Hiya, >> >> All interesting reading - thank you for one, from me! >> >> I brought up OCTANE just to see. But also previously brought up the >> FREE / Open Source >> physically based and unbiased rendering engine that is LUXRENDER: >> >> http://www.luxrender.net/ >> >> Access to this from RS because it is free and therefore accessible >> to more than FRY which has a far higher cost. >> >> Aidan >> >> On 20 July 2010 17:24, Rakesh Malik <[email protected]> wrote: >>> >>> I think a version of Larrabee will be released soon -- though it's not >>> likely to be a graphics chip, it's most likely to be a mini-supercomputer >>> on >>> a card. >>> The margins in that arena are much better than the margins in CPU's right >>> now, so you can bet that Intel's going to go after it with some gusto. >>> OpenMCL and DirectX are our best bets for "standardized" API's. OpenGL >>> will >>> always be playing catchup, and DirectX will always be leading the way, >>> because Microsoft makes too much money from games to stop pushing DirectX >>> as >>> much as it can, and OpenGL is a standard that requires a committee to >>> agree >>> on. The same committee that ensures that OpenGL is OpenGL also slows it >>> down >>> -- it's the tradeoff for standardization. >>> Threading in Python is a joke. I've done it, it's a waste of effort. The >>> language is suitable only for embarrassingly parallel applications, and >>> that's it. >>> C++0x won't be usable by very many people -- especially the newer >>> programmers. It will be a fine language, but the people using it will be >>> limited to supercomputer models, games, and the better 3D animation and >>> rendering software. >>> There are several modern programming languages that are placing a strong >>> emphasis on parallel, multi-threaded, distributed, and functional >>> programming. In "mainstream" programming, applications will just get >>> buggier >>> and more bloated. In the smaller space of 3D software and games, we'll >>> see >>> some amazing stuff, probably in the next couple of years. >>> They're going to have no choice as far as standards -- there will be a >>> small >>> number of languages (my guess is OpenMCL + whatever Microsoft calls >>> theirs) >>> that will end up becoming pervasive, and anyone who wants to play will >>> have >>> to support them or be kicked to the curb. >>> Thanks -- I'm trying to get out of programming so that I can do more with >>> 3D >>> and photography. I've been out of 3D for too long, because I haven't had >>> the >>> time to keep it up. >>> ----------------------------- >>> Rakesh Malik >>> http://www.whitecranephotography.com >>> http://www.flickr.com/baratheon >>> >>> >>> On Tue, Jul 20, 2010 at 6:22 AM, Jean-Sebastien Perron >>> <[email protected]> >>> wrote: >>>> >>>> Wow really interesting Rakesh. >>>> >>>> Larrabee won't be released soon, if released at all. >>>> >>>> I hope you are right, I am eager for theses new features to be open >>>> standard. >>>> As a programmer, it's even difficult to use good old OpenGl/DirectX >>>> mess. >>>> >>>> Thankyou for that long response, If you know more tell us. >>>> I will do further reading about the new GPU. >>>> >>>> The new c++ standard ( C++0x) that will be revealed the next year, will >>>> support multi threading. >>>> Like Python, most languages are now supporting parallel execution >>>> directly >>>> in the language. >>>> >>>> OpenGL, DirectX, Larrabee, ATI, Nvidia, Mac, Linux, Win ... They will >>>> never merge to any standard. >>>> >>>> I really like your landscape pictures. >>>> >>>> Jean-Sebastien Perron >>>> www.CombadZ.com >>>> >>>> On 10-07-20 02:34 AM, Rakesh Malik wrote: >>>> >>>> GPU based renderers are most likely the future. >>>> The Cell isn't it -- it's only somewhat parallel, and it's not >>>> well-suited >>>> to double precision arithmetic. It's a better suited to rendering than >>>> to >>>> gaming, but it's definitely nowhere near to being all that it's cracked >>>> up >>>> to be. >>>> The latest generation of GPU's from nVidia and AMD/ATI are, however, >>>> exactly what you're describing -- massively parallel, with extremely >>>> fast >>>> buses, and with general-purpose computing engines rather than dedicated >>>> hardware to run shaders. The latest nVidia GPU's do double-precision >>>> arithmetic well, which is specifically for high-performance computing. >>>> The consistency isn't due to the GPU's being GPU's, it's because >>>> general-purpose GPU's are relatively new, and there aren't any standards >>>> for >>>> them yet. It will change, especially with programming languages for them >>>> becoming standardized. >>>> Intel's Larabee processor is specifically geared toward general-purpose >>>> computing -- it's a collection of small, fast processors with very fast >>>> interconnects and it's well-suited to applications such as rendering. >>>> And lastly... the reason that the industry is being so conservative >>>> about >>>> parallelism is that most programmers don't understand even the simplest >>>> issues in parallel programming -- how to partition and re-assemble data, >>>> handle node failures, mutual exclusion, resource contention, that sort >>>> of >>>> thing. >>>> >>>> ---------------------------- >>>> Rakesh Malik >>>> http://www.whitecranephotography.com >>>> http://www.flickr.com/baratheon >>>> >>>> >>>> On Mon, Jul 19, 2010 at 6:46 PM, Jean-Sebastien Perron >>>> <[email protected]> >>>> wrote: >>>>> >>>>> GPU based renderer are doomed unless there is a open and documented >>>>> standard. >>>>> Like any hardware-dependent renderer they will fade over time. >>>>> >>>>> It's sad that the the Cell processor was ignored by the industry. >>>>> The Cell in the hand of good old programmers (Assembler and c++) not >>>>> (scripters) could do so much. >>>>> >>>>> I hate AMD and Intel and Arm and Motorolla, >>>>> The secret to faster computing is parallel work. >>>>> Like the hundreds of "Blitters" in the old arcade motherboard of the >>>>> 80's. >>>>> Programming in parallel require thinking, and the industry is playing >>>>> it >>>>> safe. >>>>> >>>>> We don't need 4 core we need 32 or 64 and more. >>>>> Simple core that only do floating point math vectoring. >>>>> Not all purpose crap like intel(int tel) like in integer. >>>>> >>>>> GPU are useless in generating images, no 2 videocard produce the same >>>>> result. >>>>> What is important is math math math .... Vector and matrix nothing else >>>>> And still to this day, only one processor in the world deliver that : >>>>> The >>>>> Cell >>>>> >>>>> If I had the money of Bill Gate, In a year I would completely change >>>>> the >>>>> computer world. >>>>> Company are behaving like the petrol industry : holding technology, and >>>>> improving slowly to make more money. >>>>> I would have thought that buy now we would not need to think about >>>>> computing speed. >>>>> >>>>> The solution is so simple : (a really really simple RISC processor * >>>>> 64) >>>>> + a lot of memory inside the processor) in a single chip. >>>>> A computer in a chip, everything in a chip. No dedicated hardware or >>>>> instructions. >>>>> >>>>> Actually not all of the above is true, but mostly true >>>>> >>>>> Jean-Sebastien Perron >>>>> www.CombadZ.com >>>>> >>>>> On 10-07-19 04:00 PM, aidan o driscoll wrote: >>>>>> >>>>>> OR http://www.refractivesoftware.com/ >>>>>> >>>>>> Octane Render is the world's first GPU based, un-biased, physically >>>>>> based renderer. €99 >>>>>> >>>>>> Bought this recently on offer - €49. Very nice renderer too. Use it >>>>>> with >>>>>> Modo! >>>>>> >>>>>> Plugs for other apps being developed for this also .... >>>>>> >>>>>> Aidan >>>>>> >>>>>> On 19 July 2010 20:42, Neil Cooke<[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> Nice Archviz there Arfo!!! >>>>>>> Thanks >>>>>>> Neil Cooke >>>>>>> PS: I dont know enough about renderers to comment and RS does it Ok >>>>>>> for >>>>>>> me >>>>>>> ... in my ignorance perhaps. >>>>>>> ________________________________ >>>>>>> From: Arjo Rozendaal<[email protected]> >>>>>>> To: [email protected] >>>>>>> Sent: Tue, 20 July, 2010 6:36:03 AM >>>>>>> Subject: RE: Fryrender plugin support >>>>>>> >>>>>>> Hi Jason, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think Realsoft really needs a better render engine. But rendering >>>>>>> with >>>>>>> third party plugins would mean some serious changes. Solid objects >>>>>>> won't be >>>>>>> possible, everything will have to be turned into SDS/polygonal >>>>>>> objects. >>>>>>> VSL >>>>>>> will be of no use anymore. All the materials will have to be created >>>>>>> to >>>>>>> work >>>>>>> with the render engine. I doubt if this is what most Realsoft users >>>>>>> like. I >>>>>>> always liked the special things of Realsoft like the VSL and solid >>>>>>> objects. >>>>>>> I'm afraid the mainstream production market is quite covered by the >>>>>>> other >>>>>>> apps. So I guess Realsoft is more for the users that like the special >>>>>>> options. >>>>>>> >>>>>>> However I must admit that these specialties have some severe >>>>>>> limitations. In >>>>>>> terms of production, VSL is far too technical and time consuming to >>>>>>> create >>>>>>> nice materials. Solids have limitations if you want to add bevels, >>>>>>> deform >>>>>>> them or things like that. >>>>>>> >>>>>>> But if Vesa and Juha find some solution that could bring the high >>>>>>> quality >>>>>>> rendering to Realsoft without losing VSL and solids it would be very >>>>>>> impressive. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Anyway, I'm even not sure if Fryrender is the best choise. I chose >>>>>>> Vray, >>>>>>> which is not an unbiased renderer lik Fry or Maxwell. But it's a lot >>>>>>> faster. >>>>>>> >>>>>>> And IMHO it renders very nice images too. But as always there are a >>>>>>> lot >>>>>>> of >>>>>>> different opinions when it comes to choosing a render app. And all >>>>>>> the >>>>>>> software galeries show the nicest results of their users. Here are >>>>>>> some >>>>>>> results of myself: >>>>>>> >>>>>>> Two different interior projects I did this year (rendered with Vray): >>>>>>> http://www.xs4all.nl/~joly/show/kantoor.html and >>>>>>> http://www..xs4all.nl/~joly/show/wrobel.html >>>>>>> >>>>>>> Both completely different atmosphere in terms of style. Modern/clean >>>>>>> office; >>>>>>> the other an private flat in Paris. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Arjo. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Van: [email protected] >>>>>>> [mailto:[email protected]] Namens Jason Saunders >>>>>>> Verzonden: maandag 19 juli 2010 17:03 >>>>>>> Aan: [email protected] >>>>>>> Onderwerp: Fryrender plugin support >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any votes for development starting on a plug-in for using this render >>>>>>> engine >>>>>>> in Realsoft ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Seeing as all the other major and not so major 3D apps have it >>>>>>> supported, >>>>>>> makes sense to try and catch up me thinks. >>>>>>> >>>>>>> >>>>>>> >>>>>>> www.randomcontrol.com/fryrender-gallery >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jason >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >>> >> > >
