POV-Ray : Newsgroups : povray.general : Using "Luxray.dll" as part of POV-Ray? Server Time
2 May 2024 14:00:28 EDT (-0400)
  Using "Luxray.dll" as part of POV-Ray? (Message 1 to 2 of 2)  
From: Theogott
Subject: Using "Luxray.dll" as part of POV-Ray?
Date: 1 Jan 2016 04:20:00
Message: <web.568643be70e4a173adb2e4f80@news.povray.org>
As i have read, "Luxray" is a DLL that includes support for GPU (via OpenCL) and
can freely be used for anybody's Rendering Project - even commercial projects.
It may also contain support for Network Rendering.

Lets say you can attach it to POV-Ray in some way. Would you save work that you
could use on another edge?

Could it be used for POV-Ray to make new Features available?

If i take a closer look on some expensive commercial render apckages, i have the
idea that some of these use at least partts of Luxray "under the hood".
So POV-Ray could also do it.

From:
http://www.luxrender.net/wiki/LuxRays

License

All the code included in LuxRays repository (i.e. LuxRays, LuxCore, LuxCore
implementation aka SLG) has been released under a new license: Apache Licence
2.0. It is a very liberal license allowing the use of the code inside commercial
products too.

Features

LuxRays will have the following list of features (in bold the features already
implemented):

C++ API;
a wrapper written in C in order to expose the API to C application too;
Multiple OS support (i.e. Linux, Windows, MacOS);
Multiple hardware support (i.e. ATI and NVIDIA via OpenCL);
Support for rendering over a wide range of heterogeneous devices like CPU, GPU,
CPU+GPU, CPU+Multiple-GPUs;
a level of abstraction over rendering device available with support for:
OpenCL devices (CPUs, GPUs, etc.);
Native threads;
NVIDIA CUDA support may be added in the future even if it is not planned at the
moment.
A wide range of accelerator structure (i.e. BVH, QBVH, KD-Tree, etc.);
triangle mesh primitive support (support for other kind of primitive may be
added in the future);
low GPU memory foot print because accelerating only the process of ray
interactions (i.e. no need to use GPU memory for texture maps, materials, frame
buffer, etc.);
support for Virtual Devices (i.e. many GPUs seen as a single device or one GPU
seen as multiple devices).
LuxRays is mainly developed to accelerate off-line renderings. Even if the
current generation of GPUs are so fast to offer near real-time rendering time,
we are going to optimize for bandwidth (i.e. number of ray intersections per
seconds) over latency.

From:
http://www.luxrender.net/wiki/LuxRays

From:
https://bitbucket.org/luxrender/luxrays/src

LuxRays is the part of LuxRender dedicated to accelerate the ray intersection
process by using GPUs.

You can find more information about the ongoing effort of
integrating OpenCL support in LuxRender at
http://www.luxrender.net/wiki/index.php?title=Luxrender_and_OpenCL
and at http://www.luxrender.net/wiki/index.php?title=LuxRays


Post a reply to this message

From: clipka
Subject: Re: Using "Luxray.dll" as part of POV-Ray?
Date: 1 Jan 2016 13:26:16
Message: <5686c4c8$1@news.povray.org>
Am 01.01.2016 um 10:15 schrieb Theogott:
> As i have read, "Luxray" is a DLL that includes support for GPU (via OpenCL) and
> can freely be used for anybody's Rendering Project - even commercial projects.
> It may also contain support for Network Rendering.

Just for the records: The name is LuxRays, not LuxRay.

> Lets say you can attach it to POV-Ray in some way. Would you save work that you
> could use on another edge?
> 
> Could it be used for POV-Ray to make new Features available?

Possibly, in theory. But...:


> License
> 
> All the code included in LuxRays repository (i.e. LuxRays, LuxCore, LuxCore
> implementation aka SLG) has been released under a new license: Apache Licence
> 2.0. It is a very liberal license allowing the use of the code inside commercial
> products too.

The FSF considers the Apache 2.0 license to be compatible with the GPL
3.0, but we'd have to examine whether it is also compatible with the
AGPL 3.0 (strictly speaking AGPL 3.0 and GPL 3.0 are mutually incompatible).


> Features
...
> triangle mesh primitive support (support for other kind of primitive may be
> added in the future);

That makes it a no-go for POV-Ray; any library that is limited to a
fixed set of primitives is of no use for us.


If the library should ever provide an interface to support custom
primitives, it might be worth investing time to examine whether (and if
so, how) it could be integrated into POV-Ray's internal workflow. Until
then, any further discussion about it is, unfortunately, completely moot.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.