Searches without login should now work. You must get asked to click a button.
Port details
luxrenderPhysically based and unbiased rendering system
1.6_15graphicsΣ=0 1.6_15Version of this port present on the latest quarterly branch.
BROKEN: fails to build with boost 1.70, see bug 236599 DEPRECATED: Depends on expiring graphics/embree This port expired on: 2019-09-04 IGNORE: is marked as broken: fails to build with boost 1.70, see bug 236599
LuxRender is a physically based and unbiased rendering engine. Based on
state of the art algorithms, LuxRender simulates the flow of light according
to physical equations, thus producing realistic images of photographic
quality. Some of the main features of LuxRender are:
* biased and unbiased rendering: Users can choose between physical
accuracy (unbiased) and speed (biased);
* full spectral rendering: Instead of the RGB colour spectrum, full
spectra are used for internal calculations;
* hierarchical procedural and image based texture system: Procedural and
image based textures can be mixed in various ways, making it possible to
create complex materials;
* displacement mapping and subdivision: Based on procedural or image
textures, object surfaces can be transformed;
* network and co-operative rendering: Rendering time can be reduced by
combining the processing power of multiple computers;
* perspective (including shift lens), orthographic, and environment
cameras;
* HDR output: Render output can be saved in various file formats,
including .png, .tga, and .exr.
Fully functional exporters are available for Blender and Maya, while
exporters for a growing number of 3D applications are under development.
WWW: http://www.luxrender.net/
===> The following configuration options are available for luxrender-1.6_15:
FREEIMAGE=off: Build with FreeImage (otherwise use OIIO only)
X11=on: X11 (graphics) support
===> Use 'make config' to modify these settings
Mark QT4 ports/functionality for removal on 2019-03-15
While here, chase some KDE4 ports and functionality, these are scheduled for
removal on 2018-12-31. Change the default option/flavor to QT5 where applicable
or use alternative toolkits like GTK.
Submitted by: tcberner
Reviewed by: adridg, jhale, rene, tcberner
Approved by: portmgr (implicit, flavor hook)
Differential Revision: https://reviews.freebsd.org/D17741
Change x11/xorgproto to become a build dep
Change x11/xorgproto to become a build time dependency when added to
USE_XORG. Change the dependency to be on the port, rather than a file the
port installs.
Fix fallout.
Bump portrevision on depending ports.
PR: 230909
Reviewed by: eadler
Approved by: portmgr (antoine)
Obtained
from: https://github.com/FreeBSDDesktop/freebsd-ports/tree/feature/xorgproto
exp-run: antoine
Differential Revision: https://reviews.freebsd.org/D16906
Replace bsd.qt.mk by Uses/qt.mk and Uses/qt-dist.mk
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: -https://reviews.freebsd.org/D15540
devel/boost-python-libs got forgotten in the python flavorization, fix
this oversight.
Reviewed by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D14368
Make ninja opt-out in cmake.mk
Using ninja instead of make (1) can lead to significant speed ups while
building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
Revision bump of all ports with USE_GL after consolidation of mesa-libs
Approved by: swills (mentor)
Differential Revision: https://reviews.freebsd.org/D10845
- Update LuxRender modern (Embree-based) branch to version 1.6
- Move DISTFILES setting back to master port exclusively as upstream had
used correct (coherent with v1.4) tags for v1.6 this time
- Register mutual port install-time conflict (CONFLICTS_INSTALL)
- Create convenience symlink in `post-extract' rather than `pre-patch',
because `200:dos2unix' bogusly(?) runs before `300:pre-patch'
- Since luxrays' library samples are not built as of r410138, do not try
to patch them (GC currently no-op patches)
- For the same reason, do not request GLUT, GLEW, and execinfo libraries
that were only used when building samples
- Convert FreeImage to an option (mandatory for v1.4) and default to off
- Update to version 1.5.1 which fixes a few annoying issues with glossy
materials when using the new LuxCore rendering modes
- Because upstream did not use different tag names for LuxCore and LuxRender
this time, avoid distfile name clash by using .tar.gz format for smaller
distfile (3.1M) and .tar.bz2 for the larger one (28M)
- Ensure that correct build number is reported in the "About" dialog box
- Fix USES and DISTVERSION check for version 1.4 support while I'm here
Update LuxRender to version 1.5. As it now requires `graphics/embree'
which is not available on 9.X for the moment, preserve version 1.4 as
`graphics/luxrender14' slave port.
- Do not embed revision hashes inside patches by creating a symlink
with constant name in `pre-patch' stage
- Add explanatory comment on why do we want to link Boost libraries
dynamically while I'm here
Consistently spell out ONLY_FOR_ARCHS_REASON due to SSE (and other SIMD
instructions) use. Particularly, saying "SSE extensions" is superfluous,
as SSE abbreviation itself means "Streaming SIMD Extensions". Correct
way to refer to particular (CPU-agnostic) technology is "SIMD instruction
set", which is not limited to MMX, SSE family, AVX, NEON, etc.
Since "instruction set" looks a bit too formal in the option description,
use more casual and shorter word "instructions".
- Belatedly update to version 1.4 (switch to DISTVERSION to make testing
of -RC versions easier)
- Point MASTER_SITES to fetch distfiles from Bitbucket (src.luxrender.net
redirects there now)
- Add two new USES: `execinfo' and `python:version'; the latter is needed
to avoid build breakage when both Python 2.x and 3.x are installed
- Remove `-pedantic' from CMAKE_CXX_FLAGS to allow building with GCC 4.2
by avoiding "floating constant exceeds range of 'long double'" error
- Reword X11_DESC slightly while here in order to insert space in "Qt 4"
while retaining visual appeal of option description text in the dialog
Uses/cmake.mk: Replace CMAKE_ENV with CONFIGURE_ENV.
Instead of defining a variable that is almost always based on CONFIGURE_ENV,
just use CONFIGURE_ENV directly.
This also matches the behavior of other ports that do not use autotools (so
most ports can just worry about CONFIGURE_ENV). Additionally, the fact that
we do not use ?= means we do not have problems if another file in Uses/
needs to set CONFIGURE_ENV (with CMAKE_ENV, the order of the arguments to
USES would matter).
Ports which set CMAKE_ENV have been adjusted accordingly. In most cases,
CMAKE_ENV was just replaced with CONFIGURE_ENV, the exceptions being:
* databases/sqliteman: CMAKE_ENV line removed; setting QMAKESPEC there has
no effect on the build system.
* devel/freeocl: CMAKE_ENV line removed; FREEOCL_CXX_COMPILER is already
retrieved from the CMAKE_CXX_COMPILER variable in the build
system.
* graphics/openimageio: CMAKE_ENV line removed; setting Qt variables there
has no effect on the build system.
Reviewed by: makc
Differential Revision: https://reviews.freebsd.org/D3403
Update the default version of GCC in the Ports Collection from GCC 4.7.4
to GCC 4.8.3.
Part II, Bump PORTREVISIONs.
PR: 192025
Tested by: antoine (-exp runs)
Approved by: portmgr (implicit)
Upgrade OpenEXR and ilmbase to 2.2.0.
GCC 4.2 in FreeBSD 8.X/9.X base is now too old to compile OpenEXR, so
GCC-based systems will upgrade to the default ports compiler (GCC 4.7
currently.)
Add two patches to OpenEXR to permit building it in a live system with
the older OpenEXR version installed. Bug report filed to upstream Github
at https://github.com/openexr/openexr/issues/130
Couple OpenEXR more tightly to ilmbase and require its exact .so
version.
Add UPDATING note, and bump PORTREVISION of all dependent ports.
Proto-STAGE hugin-devel, and mark it IGNORE because hugin is newer.
Approved by: portmgr (implicit for bumping PORTREVISION on unstaged ports)
Since v1.55, Boost is built with a modern compiler, which is known to break
linking with code built with our legacy GCC v4.2. Switch to dynamic linking
for Boost libraries as a work-around for infamous "local symbol discarded in
section `.text...' from some_static_lib.a(some_object.o)" errors.
Reported by: pkg-fallout
Convert USE_BISON to USES= bison
It brings bison as a build dependency in case it is set the following way:
USES= bison or USES= bison:build
it brings bison as a run dependency in case it is set the following way:
USES= bison:run
it brings bison both as a run and build dependency in case it the set the
following way:
USES= bison:both
While here trim some headers
Convert some USE_GNOME= gnomehack to USES= pathfix
- Update DESKTOP_ENTRIES:
* rephrase Comment field or use port ${COMMENT} if appropriate
* adjust Icon field according to the Desktop Entry Specification
* update Categories field: remove deprecated category Application;
set main category if missing
- Remove indefinite article and/or rephrase COMMENT
Approved by: portmgr (bapt), maintainer silence (12 days)
- Update to version 0.7.1 and unbreak
- Make as MAKE_JOBS_SAFE
- Introduce GUI options (Qt4 and wxWidgets)
- Utilize PORTNAME where appropriate
- Add LICENSE (GPLv3)
LuxRender is a physically based and unbiased rendering engine. Based on
state-of-art algorithms, LuxRender simulates the flow of light according
to physical equations, thus producing realistic images of photographic
quality.
LuxRender is free software -- both for personal and commercial use -- and
is licensed under the GPL. Fully functional exporters are available for
Blender and Maya, while exporters for a growing number of 3D applications
are under development.
WWW: http://www.luxrender.net/
