Compiling on Microsoft Visual C++

radiance-dev
1

Hi,

I'm Tom, and a guraduate student in Japan.
I joined this ML today, and I want you to tell me
how to compile the radiance code(rad3R5.tar.gz)
on Microsoft Visual C++.

(If you think I'm reffering to the improper topic in this ML,
I have to say I'm sorry, and please ignore this mail.)

Although I tried to find the source code set for Visual C++
using search engines, but I could not.
First, I want to know whether such program code set exists.
If there is no code set, I want you to tell me the way
to easily compile on Microsoft Visual C++, if any.

I'm often using Visual C++ 6.0 now in order to handle/create
C or C++ program, and trying to customise the radiance program
from now on.

I'm sorry to spare your precious time.

···

--
Tom <[email protected]>

2

Compiling Radiance under Visual C++ is actually pretty
easy.

Look into Rmakefile file in each source directory.
Even if you are not familiar with UNIX makefiles it is
pretty clear which sources go into which
program/library and what gets linked to what.

I would suggest to start with common directory and
create the library which then gets linked into almost
every Radiance program.

This is where the problems start because some files
simply won't compile. For example, malloc.c won't
compile because Windows has no sbrk() call. One file
does ++ on void pointer and VC++ doesn't like it.
Other files assume you have X11 or OpenGL headers.
Etc.

My suggestions is to initially simply exclude the
files that won't compile and resolve porting issues
only when and if you get linker errors.

I started creating MS IDE project files (but for
Visual Studio .NET 2003, i.e. compiler version 7.1
rather than 6) but then got sidetracked into Fast
Fourier Transforms, SIMD and such stuff. For this I
needed only common (librt) library and image decoding
programs(in px directory) and it didn't take more than
an hour to get these programs running.

Rpict, rview and such programs require much more work.

Tony

···

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

3

Hi Tony & Tom

making Radiance compile under C++ is not difficult in principle, but just a little tedious as you have to hunt down a lot of minor issues. You've already mentioned some, others are eg. the K&R vs ANSI question, esp. the stricter prototyping requirements of C++.

For those who are interested:
There's a C++ version of Radiance available, however, this is not original Radiance anymore as I performed some considerably changes
(added new features/deprecated some of the old ones), and it's still a work in progress, currently focusing only on the rendering programs rpict/rview.
see http://www.cb-d.de/radzilla.html

It is of course pure UNIX flavour, compiles wich GNU g++, but still contains X11 headers, symbolic links in the source tree and certainly some other issues not MS compatible of which I'm not even aware of (I know pretty little about the whole Michealsooft stuff, so I cannot offer any help in this respect :slight_smile:

-cb

4

Tom wrote:

Hi,

I'm Tom, and a guraduate student in Japan.
I joined this ML today, and I want you to tell me
how to compile the radiance code(rad3R5.tar.gz)
on Microsoft Visual C++.

(If you think I'm reffering to the improper topic in this ML,
I have to say I'm sorry, and please ignore this mail.)

Although I tried to find the source code set for Visual C++
using search engines, but I could not.
First, I want to know whether such program code set exists.
If there is no code set, I want you to tell me the way
to easily compile on Microsoft Visual C++, if any.

I'm often using Visual C++ 6.0 now in order to handle/create
C or C++ program, and trying to customise the radiance program
from now on.

- Get and install Python: http://www.python.org/
- Get and install SCons: http://scons.sourceforge.net/
- Get and install the Radiance HEAD dump and auxiliary package
  (the 3.5 release won't work).
- Open a command console (DOS box), and change to the "ray"
  directory of the Radiance source tree.
- Run the command "scons install" in that directory.
  (You may need to give the full path to the SCons batch file)
- Wait.

This will build and install *most* of Radiance, using the most
current VC version found on the system. There are a few parts
that still need to get ported, such as the holodeck, the GUI
programs, and some other minor stuff. The default installation
location for Windows is under "C:\radiance3.6a\". You may need
to set the correct RAYPATH for everything to work properly.
Actually, I'm not sure if it will actually *work*... :wink:
I have done a few simple tests, and I don't remember any major
hickups. If you (or someone else) find any, feel free to report
and/or fix at your leisure.

If you want it to install in a different location, then you
have two possibilities:

* Either add the variables RAD_BINDIR, RAD_MANDIR, and RAD_RLIBDIR
  to the SCons command line like this:
  "scons RAD_BINDIR=c:\where\ever\bin install"
  (add the other two as well).

* Or make a copy of the file "platform\win32.cfg" to
  "platform\win32_custom.cfg" and change the respective variables
  in the new copy. Note that in this case those three variables
  are relative to RAD_BASEDIR. If such a *_custom.cfg file
  exists, then it will take precedence over the original.

If you need the missing parts as well, then you'll have to resort
to Cygwin, SCons will work there as well. In fact, the SCons
build system works on all platforms supported by Radiance, as an
alternative to the traditional makefiles.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

5

Tonko Juricic wrote:

One file
does ++ on void pointer and VC++ doesn't like it.

Did you report this? We need to know about all bugs that you find
(unless you're talking about 3.5, in that case we don't care).

I started creating MS IDE project files

Don't do that. Use the SCons system instead.
That works exactly the same on all platforms, and already knows
which source files and includes are required on each.

Rpict, rview and such programs require much more work.

Rpict compiles fine on Windows, although you'll have to test
yourself if it works well enough for your purposes.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

6

Hey Carsten,

great site! I liked photon mapping integration and may
end up "stealing" some code from you :slight_smile:

I liked your comments about C++ porting because I was
toying with the idea of OO-ing Radiance for some time
but then I started thinking: what parts of code would
really profit from OO-ing it, both performance and
extensibility-wise?

As I haven't found a satisfactory answer to this
question I decided not to mess with it. Eventually,
interfacing Radiance to other packages (often written
in C++) may make me understand these issues better.

My current approach is: as little changes as possible.
For example, I included bmalloc.c in library build
simply because it will take more #ifdef _WIN32 in the
other code that calls bmalloc, than casting void* to
(char*) before incrementing it.

In any case, your experiences with porting to C++ are
very valuable and interesting to me.

Thanks,
Tony

···

--- Carsten Bauer <[email protected]> wrote:

For those who are interested:
There's a C++ version of Radiance available,
however, this is not
original Radiance anymore as I performed some
considerably changes
(added new features/deprecated some of the old
ones), and it's still a
work in progress, currently focusing only on the
rendering programs
rpict/rview.
see http://www.cb-d.de/radzilla.html

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

7

Did you report this? We need to know about all bugs
that you find
(unless you're talking about 3.5, in that case we
don't care).

Isn't this place Ok to reprt? Anyway, I am looking
into CVS from Web site and bmalloc.c has:

static void *bposition = NULL;
....
  bposition += n;

and in few places more in the same file.

> I started creating MS IDE project files

Don't do that. Use the SCons system instead.
That works exactly the same on all platforms, and
already knows
which source files and includes are required on
each.

I am using it is as complementary, not as a system
build substitute for SCons.

The problem is, I just can't work normally without my
familiar IDE, IDE's editor, shortcuts and the stuff.

Following the code execution in debugger is a great
learning tool for me.

In order to play I need to read the code, change,
compile, debug, try this, try that. After all these
years I can not switch to Windows version of vi editor
and drop to command line to recompile/relink each and
every time.

Tony

···

--- Georg Mischler <[email protected]> wrote:

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

8

Tonko Juricic wrote:

Isn't this place Ok to report?

Yes of course. Just that I haven't heard of this specific
item before.

Anyway, I am looking
into CVS from Web site and bmalloc.c has:

static void *bposition = NULL;
....
        bposition += n;

and in few places more in the same file.

That's interesting... And it's probably me who changed the
declaration from a char* to a void* in my ANSIfication efforts.

But you're right. Even if most compilers allow it, by the books
it's not legal to do pointer arithmetic with void pointers.
The solution is probably to just change it back:

static char *bposition = NULL;

Since bposition is only accessed within those two functions,
and it only gets assigned void pointers, that should work just
as fine as it did before my change. I've just checked the fix
into CVS, so it should be in tomorrows HEAD dump.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

9

Hi Tonko,

what parts of code would
really profit from OO-ing it, both performance and
extensibility-wise?

As I haven't found a satisfactory answer to this
question I decided not to mess with it. Eventually,

these questions are really difficult to answer. The overwhelming majority of the core code (esp the calculation stuff like octree traversal, ray intersections, material behaviour etc etc) is already highly optimized and is better left as it is (which is what I did, apart from ANSIfying or rearranging)

The main justification of the project certainly is it's role as a hands on learning thing.

The key problem is that one could do everything different if one started completely from scratch. In this case, I always would use C++. But this was/is of course impossible (would be unnecessary, too), so I contented myself which the experiences gained without implementing/changing everything what could theoretically have been done. In some of my extensions, however, I greatly benefitted from C++. And if there will ever be a situation, where a larger team might be in charge for the further Radiance development, a C++ base would of course be a plus, too. As this isn't the case, the question is of no importance.

-Carsten

PS feel free to mess with the code. I should apologize for the missing documentation so far, you know, the usual lack of time :slight_smile: But I'm always open for questions and private communication

10

snicker, snicker, snicker...

Randolph

···

On Sun, Oct 03, 2004 at 04:50:14PM -0400, Georg Mischler wrote:

Tonko Juricic wrote:

> Isn't this place Ok to report?

Yes of course. Just that I haven't heard of this specific
item before.

> Anyway, I am looking
> into CVS from Web site and bmalloc.c has:
>
> static void *bposition = NULL;
> ....
> bposition += n;
>
> and in few places more in the same file.

That's interesting... And it's probably me who changed the
declaration from a char* to a void* in my ANSIfication efforts.

But you're right. Even if most compilers allow it, by the books
it's not legal to do pointer arithmetic with void pointers.
The solution is probably to just change it back:

static char *bposition = NULL;

Since bposition is only accessed within those two functions,
and it only gets assigned void pointers, that should work just
as fine as it did before my change. I've just checked the fix
into CVS, so it should be in tomorrows HEAD dump.

-schorsch

--
Georg Mischler -- simulations developer -- schorsch at schorsch com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

_______________________________________________
Radiance-dev mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-dev

11

Um, that was supposed to be quiet snickering...

oh, well.

Randolph

12

Hi all,

Thank you so much for your kindness.
I'm suprised to get much more information than I expected.

Now I've not yet read your mail intensively, but I knew what to do
at the beginning.
Please help me again if I have some questions.

Thank you again!

Regards,

Tom

···

--
Tom <[email protected]>

13

Now I'm struggling with running SCons...

In the following instruction,

- Get and install Python: http://www.python.org/
- Get and install SCons: http://scons.sourceforge.net/
- Get and install the Radiance HEAD dump and auxiliary package
  (the 3.5 release won't work).
- Open a command console (DOS box), and change to the "ray"
  directory of the Radiance source tree.
- Run the command "scons install" in that directory.
  (You may need to give the full path to the SCons batch file)
- Wait.

What is "the Radiance HEAD dump and auxiliary package"?
I think it is kind of "SConstruct" file, but I don't know
wheter I can get it by downloading in the radiance site or
by making by myself.

Please tell me where it is or how to make?

Thank you,

Tom

···

--
Tom <[email protected]>

14

Hi Tom

yepp, now you see where you are, Radiance is indeed complex and you notice the complexity right form the beginning :slight_smile:

It's always the same problem, for those working already with it everything has become self-evident, and its difficult to imagine how a beginner might see it..

1)
there is a so called 'official' RADIANCE version 3.5, which can be downloaded from the official radsite.lbl.gov

this contains everything you need in one package

2)
this 'official' version is not really up to date, there is a continously improved RADIANCE version, which is called RADIANCE-HEAD, containing the latest bugfixes and some new features. This can be downloaded from radiance-online.

But the HEAD - Version is split into two parts, the rendering and postprocessing programs and - the second part - a collection of library files '.cal-files' (<- after some time spent with RADIANCE you'll know what these are) etc, etc. This is called the auxilary package and has to be downloaded separately (also from radiance-online)

3) not to be mixed up with this auxiliary package is the SCons and Python stuff.

Radiance contains an installation script based on the classic UNIX shells (C-shell) to perform all the tasks necessary to install it

Georg Mischler has added a second possibility to install RADIANCE with help of a publicly available tool called SCons, which itself needs Python. So if you want to go the SCons way for the installation, you have to get that tool of course.

-cb.

15

All in all, README file wouldn't hurt. I am involved
in a couple of other open source projects and it is
always the same story : you spend enormous time
learning how to build. That's why I like those
projects that settled for complementary approach -
generic build tool+separate directories for specific
IDE builds. The problem with adding the latter is that
there is another set of files that have to be
maintained separately, but for some popular Source
Forge projects it is obviously not a problem.

Tony

···

--- Carsten Bauer <[email protected]> wrote:

Hi Tom

yepp, now you see where you are...

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

16

Hi Carsten,

Since you rewrote bits of radiance to c++ I was wondering if you had tingled with a windows parallelization ? And if you have had looked into SIMD instructions? Seems like there is a lot of performance to be gained there even on CPU.

17

Unfortunately, you are responding to a 20 year old post and Carsten doesn’t seem to be active here anymore. @Roland_Schregle1 did a c++ port but I don’t remember the details, there was also Accelerad, a partial SIMD version, developed at MIT, but I don’t know its status, either.

18

Hi Mathias,

I am sure that Greg could give a nice workshop presentation on why this is a complex topic.

In layman’s words, distributed ray-tracing (meaning ray-tracing that accounts for diffuse inter-reflection) is a typical case of a recursive algorithm, that is kind of a worst-case for fine-grained parallelization. In particular with optimizations such as the ambient cache.

Radiance offers parallelization at two higher levels - tracing each eye ray indepently (rtrace or rtpict -n #PROCESSES), and parallel processing of image tiles (rpiece). Here, a certain performance potential might be to replace processes by threads. But I would not expect ground-breaking speeds from it, and it leads to the question of portability (one can either write platform-specific code, or rely on high-level constructs that contradict the current policy to rely only on a ANSI-C compliant compiler).

As far as I know, all modern compilers support the automatic generation of SIMD instructions. However, the effect is limited. You can, e.g. perform instructions on vectors XYZ or RGB.

Since Roland was mentioned - the photon-distribution pass in the photon map module could probably be parallelized with less problems, since each photon is independent from all others. However, a lot of the time is spent on sorting photons, and this is already less easy to be parallelized and may be io-bound anyway.

Probably the most promising and safest approach - to avoid future head-aches in maintaining the software - would be to get rid of obstacles that hinder the rapidly auto-parallelization capabilities of modern compilers to do the job. Candidates would be global variables and deeply nested loops. Ideally, a compiler switch should then produce code that makes use of the target platform.

Best, Lars.

1 Like
19

If you disabled the irradiance cache, set ad to 1 and scale resolution like mark j stocks’ approach then it should be highly parallelizable even GPU parallelizable, no?

20

Yes, without the ambient cache, Monte Carlo ray-tracing is “embarrassingly parallel” as they say. However, you waste a lot of time re-computing the same values without caching, so it’s not a guaranteed win.

The biggest challenge is reimplementing Radiance for the GPU. It’s not like you can just throw a different C compiler at it. Everything needs to be rewritten from scratch. @Nathaniel_Jones did much of this work in his Accelerad software, but some challenging stuff is missing, such as BSDFs and similar advanced materials.

It’s a complex subject, and I’m sure others have more to say on it. I come from the perspective of seeing many GPU architectures come and go over the years, and being grateful that I didn’t waste much time on them.

Of course, standardization has improved significantly, and Nvidia seems to dominate the market now, but who knows how long that will last? I have code I haven’t touched in 3 decades in Radiance. Does anyone have GPU code still working from the 90’s?

Cheers,
-Greg