Announce: 3Delight Renderer
patrick_...@my-deja.com
as those of you who were at Siggraph may know,
3Delight is now available for free at
www.3delight.com.
3Delight is a fast REYES renderer that supports
ray tracing, motion blur, depth of field and
programmable shaders (including displacement and
atmosphere shaders). It implements the RenderMan
interface and uses the RenderMan shading language.
It is available for IRIX, Linux Intel, Linux
PowerPC and Windows platforms.
We uploaded version 0.5.1 yesterday. This version
has an enhanced ray tracer, fixes some bugs and
adds support for new SL functions.
Patrick Fournier
The 3Delight developer team
pat...@3delight.com
Sent via Deja.com http://www.deja.com/
Before you buy.
pat...@3delight.com
availablefor free at www.3delight.com.3Delight is a fast REYES renderer that
supports ray tracing, motionblur, depth of field and programmable shaders
(including displacementand atmosphere shaders). It implements the RenderMan
interface and usesthe RenderMan shading language. It is available forIRIX,
Linux Intel, Linux PowerPC and Windows platforms.We uploaded version 0.5.1
yesterday. This version has an enhancedray tracer, fixes some bugs and adds
support for new SL functions.Patrick FournierThe 3Delight developer
Skint
writing your own driver - I know it doesn't make any difference, but the one
drawing to screen from the centre outwards reminded me a lot of the new
SoftImage XSI quick render region operation. A lot more stable than the BMRT
framebuffer too - like you can have windows go over it and you don't loose
the bloody image!!
Does anyone know where there is information on writing BMRT display drivers.
cheers
Simon
----------
Larry Gritz
Skint <sib...@hotmail.com> wrote:
>Does anyone know where there is information on writing BMRT display drivers.
Precisely the same as writing PRMan display drivers.
(In fact, you can use the same driver for both.)
-- lg
--
Larry Gritz Exluna
l...@exluna.com Berkeley, CA
Alex Magidow
it to see its display drivers, apparently, and so it won't work. It
installed a bunch of registry entries, but the authors assumed it'd be
run under WinNT, which was a poor assumption, IMAO. They should check for
raw registry entries instead of relying on it to be run in that OS.
Steve Martin wrote:
> Skint wrote:
> >
> > I tried this out - not bad.
>
> Hmmm... it must just be me. I downloaded and tried to install it on
> my RH6 box, but the install script was broken. Wouldn't even execute,
> something about syntax errors where the double-brackets ([[) were.
> Never could get the silly thing to install.
--
" Force is but might", the teacher said--
"That definition's just."
The boy said naught, but thought instead,
Remembering his pounded head:
"Force is not might, but must!"
- Ambrose Bierce
Steve Martin
Will R
>In article <p0Yk5.1643$iE4....@news2-win.server.ntlworld.com>,
>Skint <sib...@hotmail.com> wrote:
>>Does anyone know where there is information on writing BMRT display drivers.
>
>Precisely the same as writing PRMan display drivers.
>(In fact, you can use the same driver for both.)
>
> -- lg
>
For those of us who have never written prman drivers, where can information be
found? I am sure I wouldn'r be able to impliment a driver if I wanted to, but
it would probably make for some interesting reading...
---------------------------
"I /want/ Moofeus!"
-The V E C T O R-
Brian
Brian Perry
Patrick Fournier
Hi,
the installation script was written for the csh shell.
Since the default script on Linux seems to be bash, you may
have trouble installing.
If csh is installed on your system, just do:
% csh
% ./install --prefix dir_to_install
% exit
You will have to modify your .profile manually to set
the environment variables, because it is likely that
the .3Delight script won't work either.
I'll try to write a script that is compatible with every
shell (or at least bash) for the next release.
Patrick
Patrick Fournier
> I'm actually having a difficult time installing it on Win98...I can't get
> it to see its display drivers, apparently, and so it won't work. It
> installed a bunch of registry entries, but the authors assumed it'd be
> run under WinNT, which was a poor assumption, IMAO. They should check for
> raw registry entries instead of relying on it to be run in that OS.
>
Hmmm... someone tried the installation script on Win98 and
told me it worked. I'll check again with him.
In the meantime, you can define manually the environment
variables needed to run 3Delight. They are describred in
the online doc:
http://www.3delight.com/online_doc/3delight_8.html#SEC8
Patrick
Alex Magidow
set DELIGHT = D:/3Delight
set DL_SHADERS_PATH = D:\3Delight\shaders
set DL_DISPLAYS_PATH = D:\3Delight\displays
set
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS;C:\WINDOWS\COMMAND;D:\BMRT2.4\bin;D:/bin;D:\Assembly;D:\pass32\bin;D:\3Delight\bin;D:\3Delight\lib;D:\3Delight\shaders;
Excuse the alternation between forward and back slashes...might that be a
problem? My computer seems to be fine with it, especially seeing as I have
cygwin installed.
Patrick Fournier wrote:
--
Libellule
The render is pretty quick, even with motion blur!
Steve Martin
> set DL_SHADERS_PATH = D:\3Delight\shaders
> set DL_DISPLAYS_PATH = D:\3Delight\displays
> Excuse the alternation between forward and back slashes...might that be a
> problem? My computer seems to be fine with it, especially seeing as I have
> cygwin installed.
I don't know that much about Win98, but I do know that DOS will burp on
forward slashes in a directory path, so yeah, that's probably not a good
thing.
Steve Martin
I was finally able to get the renderer to run after some fumble-fingered
fiddling with my environment (should have RTFM).
I'm impressed with the speed of the renderer vs. (oh, say, BMRT)
(yeah, Larry, I know I'm comparing apples with watermelons :),
but of course it has some way to go to be what I would consider
"finished". I experienced some tearing in one rendered image
when using displacement.
I didn't fiddle with the program very much at all, but it looks
promising.
Andrew Bromage
Found two bugs in 3Delight so far.
In this shader:
surface
smstep()
{
varying float min = 0;
uniform float max = 1;
uniform float x = 0.5;
varying float uuv = smoothstep(min, max, x);
}
First off, "uuv" is stored uniform, not varying. Secondly, the call
to smoothstep() causes the C++ compiler to generate an error.
This was tested on Linux i386.
Cheers,
Andrew Bromage
Justin Elliott Cobb
Bromage) wrote:
>G'day all.
>
>Found two bugs in 3Delight so far.
Lemmie tack some more on.. :-P
I'm getting bizarre artifacts on nurbs, creasing and jitters, for
instance on the side of a nurb sphere it will facet like the surface
of a zepplin, but only for one or two spans. :-P In other places I see
what looks like sections of a curved surface "detaching" and kindof
hovering offset from where they are supposed to be. I can post
examples if necessary.
And it seems to complain about the "version" statement at the top of
my RIBs, not something that BMRT, Siren, or Aqsis had any problem
with.. what version of RIB is it looking for?
This was the Win32 version, on Win2000pro.
Other than that, let me say this: If the speed of 3Delight is any
indication of what its like to work with PRman, I am getting warm
fuzzies just thinking about oneday soon, using Pixar's pride and joy.
:-)
Justin Elliott Cobb
Oh, and another thing, I find it kinda odd how 3Delight will try to
substitute shaders when it cannot find the appropriate ones. This is
an especially strange feature because it hasn't sucessfully
substituted any yet. :-P
Again, win32 version on win2k.
Steve Martin
>
> G'day all.
>
> Found two bugs in 3Delight so far.
Let me add another (which I've already sent to bu...@3delight.com):
I'm using the shader below applied to a cylinder to simulate rubber
treads on a wheel. Renders fine under BMRT, shows faceted holes in
the surface under 3delight:
displacement treads ( float number_of_treads = 40,
size = 0.2)
{
vector nn ;
float disp ;
nn = normalize(N) ;
disp = abs(sin(u*PI*number_of_treads))*size *
smoothstep(0, 0.05, v)* (1-smoothstep(0.95, 1, v)) ;
P = P + nn*disp ;
N = calculatenormal(P) ;
}
Cylinder with no displacement renders properly.
BTW, there appears also to be a slightly invalid assumption in
the scripts (both install and shadersl); the authors assume that
you're using a certain shell on your *nix system. On my RH6
box, bash chokes on the install script, and flags an error in
shadersl, both where the script uses a double bracket ('[[' or
']]'). I'm not an expert on shell programmming, but every script
I've ever looked at on this box uses single brackets in them.
I'm assuming that some other *nix (maybe SGI) might use a
shell that will accept this...
Patrick Fournier
> set DL_SHADERS_PATH = D:\3Delight\shaders
> set DL_DISPLAYS_PATH = D:\3Delight\displays
>
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS;C:\WINDOWS\COMMAND;D:\BMRT2.4\bin;D:/bin;D:\Assembly;D:\pass32\bin;D:\3Delight\bin;D:\3Delight\lib;D:\3Delight\shaders;
>
You should use forward slashes in DELIGHT, DL_SHADERS_PATH and
DL_DISPLAYS_PATH (they are read by 3Delight) and backslashes
in PATH (it is read by Windows).
BTW, you don't have to have D:\3Delight\shaders in your PATH.
Patrick
Patrick Fournier
bro...@goaway.cc.monash.edu.au (Andrew Bromage) wrote:
> G'day all.
>
> Found two bugs in 3Delight so far.
>
>
> surface
> smstep()
> {
> varying float min = 0;
> uniform float max = 1;
> uniform float x = 0.5;
> varying float uuv = smoothstep(min, max, x);
> }
>
> First off, "uuv" is stored uniform, not varying. Secondly, the call
> to smoothstep() causes the C++ compiler to generate an error.
>
the compiler optimises the generated code, that's why uuv is stored
as a uniform. If you add the line setcomp(Ci, 1, uuv), you'll see
why it has been otptimised this way.
For call to smoothstep: there was a bug in the shader compiler;
it will be fixed in the next release.
Cheers,
Patrick Fournier
<098E0578E52ACFD5.8D6908B2...@lp.airnews.net>,
sis...@hotmail.HnospamH.com (Justin Elliott Cobb) wrote:
> On 14 Aug 2000 11:08:47 +1000, bro...@goaway.cc.monash.edu.au (Andrew
> Bromage) wrote:
>
> >G'day all.
> >
> >Found two bugs in 3Delight so far.
>
>
> I'm getting bizarre artifacts on nurbs, creasing and jitters, for
> instance on the side of a nurb sphere it will facet like the surface
> of a zepplin, but only for one or two spans. :-P In other places I see
> what looks like sections of a curved surface "detaching" and kindof
> hovering offset from where they are supposed to be. I can post
> examples if necessary.
>
Can you send a RIB at bu...@3delight.com ? Thanks.
Patrick Fournier
<32F0DA5A2C2F0FB4.822EE1E2...@lp.airnews.net>,
When it does not find the shader you specify, 3Delight will try to
use the default shader for the call (matte.sl for a surface, bumpy.sl
for a displacement, spotlight.sl for a lightsource). Of course, it
is more than likely that the parameters you specified won't match
the default shader's parameters.
If DL_SHADERS_PATH is not defined or points to the wrong directory,
3Delight won't be able to load the default shaders and will use
the null shader.
Hope that helps.
Larry Gritz
Patrick Fournier <pat...@3delight.com> wrote:
>In article
><098E0578E52ACFD5.8D6908B2...@lp.airnews.net>,
>> Bromage) wrote:
>>
>> >Found two bugs in 3Delight so far.
>>
>> Lemmie tack some more on.. :-P
>
Patrick, I hope you don't mind my jumping in here, but this has been
on my mind, too.
Folks, when you find a bug in a renderer, the best thing to do is to
send private email to the renderer's author. After all, none of the
programs discussed in this newsgroup are open source, so there's only
one person (or a small team) who are able to fix the bugs anyway.
Please try to give explicit instructions about how to reproduce it
with a simple test case (preferably by sending a RIB and/or .sl
files). Only in rare cases will an error report be helpful without a
reproducing example.
Also, it's not clear what is to be gained by posting every bug report
to the newsgroup. As a renderer author, I think it's rather
counterproductive, for two reasons. First, it's much easier to track
bug reports when they come in via email than when they're in the
newsgroup. Second, things seem to last forever on news. It pains
me as an author when a bug is reported, that in five minutes could
be fixed, recompiled, and have new binaries posted on the www server,
yet the bug report is still on the newsgroup for all to see (and be
misinformed by) for weeks to come (or years, counting deja).
The exception is if the bug is very subtle and would bite many users
in unexpected ways, or if you find a clever workaround to a bug.
Those should definitely be posted here. Also, assuming that the
renderer author has been informed and can't get around to fixing the
bug for some time, it's a perfectly good idea to post the bug
description here in order to seek workarounds from others.
Justin Elliott Cobb
wrote:
>Folks, when you find a bug in a renderer, the best thing to do is to
>send private email to the renderer's author. After all, none of the
>programs discussed in this newsgroup are open source, so there's only
>one person (or a small team) who are able to fix the bugs anyway.
My rationale for posting "bug" reports on the newsgroup is that I most
often don't know if it is a bug or a stupid user error, for instance
with my problems with the 3Delight SL compiler. That turned out to be
my doing, and I think any message I sent to the developer would have
been a rather frivilous one..
I dunno, if you guys feel that's bad form however, I can certainly
amend my habits. :-)
Larry Gritz
Justin Elliott Cobb <sis...@hotmail.HnospamH.com> wrote:
>On 14 Aug 2000 10:45:22 -0700, l...@unagi.exluna.com (Larry Gritz)
>wrote:
>
>often don't know if it is a bug or a stupid user error, for instance
>with my problems with the 3Delight SL compiler. That turned out to be
>my doing, and I think any message I sent to the developer would have
>been a rather frivilous one..
Yeah, it's a fine line. You want real reports to the author, and
"what have I done wrong" messages to go to the group (to keep the
author from being swamped with help requests). Sometimes it's hard
to tell the difference, and nobody will blame you there.
The point I was trying to make was that if you are pretty convinced
it's a bug, it's more efficient and possibly more appropriate to
report it via email.
Alex Magidow
Perhaps you could have an automatic installation for those of us who are using Win9X- or at least detect it, and instead of making registry keys with the install, add
the paths automatically(and correctly, b/c I can't seem to get it to work) to autoexec.bat. Or you could just have your program check raw registry entries instead of
relying on windows to make anything in /Environment an environmental variable.
Patrick Fournier wrote:
> Patrick
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
" The enormous gap between what US leaders do in the world and what Americans think their leaders are doing is one of the great propaganda accomplishments of the
dominant political mythology. "
- Michael Parenti, political scientist and author
Steve Martin
> Let me add another (which I've already sent to bu...@3delight.com):
>
> I'm using the shader below applied to a cylinder to simulate rubber
> treads on a wheel. Renders fine under BMRT, shows faceted holes in
> the surface under 3delight:
OK, I admit to a rather bad case of cranial-rectal inversion on
this one... turns out I forgot to increase my object bounds to
allow for the displacement.
The problem with the install script remains, though.
Steve Martin
> Please try to give explicit instructions about how to reproduce it
> with a simple test case (preferably by sending a RIB and/or .sl
> files). Only in rare cases will an error report be helpful without a
> reproducing example.
A very good point, Larry. I'm a TV engineer by trade, and get trouble
calls from our news department on occasion complaining of some problem
or other with some of their equipment, many times simply "such-and-such
machine is broken, please fix it" with no more information. It's very
hard to fix a problem that cannot be demonstrated.
After reading your message, I had to agree (and humbly prostrate
myself for having committed exactly this offense, although in my
own defense I did forward a full report privately to the author,
including a RIB file and .sl file that demostrated the problem) that
it does no good posting bugs in a program to the NG if the intent is to
try to get them fixed. However, there is one good reason for pointing
out
defects in a program. If a package is a good one (whatever "good"
is defined to be), then fine. However, if one is a real dog, with
many problems, i.e. crashes frequently, won't install, can't find
such-and-such resources, incomplete, whatever, then I appreciate
seeing such information from someone who has tried it so that I
won't waste a lot of time trying to get the silly thing working
here. I guess this would qualify more as a "user report" than a
"bug report", though.
Andrew Bromage
I wrote:
>> In this shader:
>>
>> surface
>> smstep()
>> {
>> varying float min = 0;
>> uniform float max = 1;
>> uniform float x = 0.5;
>> varying float uuv = smoothstep(min, max, x);
>> }
>>
>> First off, "uuv" is stored uniform, not varying.
Patrick Fournier <pat...@3delight.com> writes:
>the compiler optimises the generated code, that's why uuv is stored
>as a uniform. If you add the line setcomp(Ci, 1, uuv), you'll see
>why it has been otptimised this way.
My mistake. This has actually been condensed from a larger example
where "min" was a varying shader parameter. In my example, "min" is
uniform (in fact it's constant!), so it's safe for uuv to be uniform
too (since smoothstep is a pure function).
Strangely enough, though, the assignment to uuv is in a SIMD loop.
Try this example instead:
surface
smstep2(varying float min = 0;)
{
uniform float max = 1;
uniform float x = 0.5;
varying float uuv = smoothstep(min, max, x);
}
In this example uuv must be varying but it is not stored as such.
Cheers,
Andrew Bromage
Stephen H. Westin
> > set DELIGHT = D:/3Delight
> > set DL_SHADERS_PATH = D:\3Delight\shaders
> > set DL_DISPLAYS_PATH = D:\3Delight\displays
>
> > Excuse the alternation between forward and back slashes...might that be a
> > problem? My computer seems to be fine with it, especially seeing as I have
> > cygwin installed.
>
> I don't know that much about Win98, but I do know that DOS will burp on
> forward slashes in a directory path, so yeah, that's probably not a good
> thing.
As I understand it, the only place where forward slashes don't work is
on the DOS command line; the command interpreter sees these as command
modifiers. Everywhere else, forward slashes work just fine.
--
-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.
Patrick Fournier
bro...@goaway.cc.monash.edu.au (Andrew Bromage) wrote:
> Try this example instead:
>
> surface
> smstep2(varying float min = 0;)
> {
> uniform float max = 1;
> uniform float x = 0.5;
> varying float uuv = smoothstep(min, max, x);
> }
>
> In this example uuv must be varying but it is not stored as such.
This is because the compiler optimizes based on the usage of the
variable. Since uuv is not used afterward, there is no need to store
it as a varying (in fact, it shouldn't be stored at all). In general,
the compiler will always try to store a varying variable as a uniform
in order to keep memory usage low.
Larry Gritz
Steve Martin <smart...@earthlink.net> wrote:
> If a package is a good one (whatever "good"
>is defined to be), then fine. However, if one is a real dog, with
>many problems, i.e. crashes frequently, won't install, can't find
>such-and-such resources, incomplete, whatever, then I appreciate
>seeing such information from someone who has tried it so that I
>won't waste a lot of time trying to get the silly thing working
>here.
Agreed. I'm all in favor of detailed reports that catalog the
strengths and weaknesses of a piece of software, or comparing
different programs to each other. And if a software truly is a
dog, I would expect people to say so, just as I'd expect them to
praise an exceptional package.
I just wanted people to cut Patrick a little slack, he's only had his
software released for a couple weeks. I know from experience that
this is a time that lots of little bugs pop up constantly, and
generally they can be fixed right away. In a few weeks or months,
we'll know a bit better what the real strengths and weaknesses of the
program are. I just know how demoralizing it is to see postings of
bugs that have already been fixed, or could be fixed almost
immediately, but the posting claiming that it's broken is there to
stay and there's no way to delete it or correct any misinformed
opinions that have formed.
Steve Martin
> I just wanted people to cut Patrick a little slack, he's only had his
> software released for a couple weeks.
Oh, I agree completely. His Web site clearly indicates that this is
"alpha" software, so one would expect some bugs.
> In a few weeks or months,
> we'll know a bit better what the real strengths and weaknesses of the
> program are.
Well, here's a post that I think Patrick won't mind being on the archive
forever... for alpha software, 3delight seems to be very promising, and
I
for one am quite impressed. I'm looking forward to its future.
Now, back to business...
Arlindo C
I have installed it on Win98...
I don't remember quite well, but don't use c:\etc\etdsdf just use
\etc\etdsdf, at least for the variable in each the differents values are
separated by :
By the way i have tryed to render an exmaple from BMRT using 3Delight, (the
vasegallery1.rib) it gives a lot of mistakes... Any idea why?!
Bye!
A. Carvalho
rdc0...@yahoo.com
Alex Magidow <ax...@mninter.net> wrote in message
news:399853EC...@mninter.net...
> I have redone my autoexec.bat, and I still can't get the silly program to
run...argh...
> Perhaps you could have an automatic installation for those of us who are
using Win9X- or at least detect it, and instead of making registry keys with
the install, add
> the paths automatically(and correctly, b/c I can't seem to get it to work)
to autoexec.bat. Or you could just have your program check raw registry
entries instead of
> relying on windows to make anything in /Environment an environmental
variable.
>
> Patrick Fournier wrote:
>
> > In article <3995FC89...@mninter.net>,
> > Alex Magidow <ax...@mninter.net> wrote:
> > > I have it in my autoexec.bat file thusly:
> > >
> > > set DELIGHT = D:/3Delight
> > > set DL_SHADERS_PATH = D:\3Delight\shaders
> > > set DL_DISPLAYS_PATH = D:\3Delight\displays
> > > set
> > >
> >
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS;C:\WINDOWS\COMMAND;D:\BMRT2.4\
bin;D:/bin;D:\Assembly;D:\pass32\bin;D:\3Delight\bin;D:\3Delight\lib;D:\3Del
ight\shaders;
> > >
> >
> > You should use forward slashes in DELIGHT, DL_SHADERS_PATH and
> > DL_DISPLAYS_PATH (they are read by 3Delight) and backslashes
> > in PATH (it is read by Windows).
> >
> > BTW, you don't have to have D:\3Delight\shaders in your PATH.
> >
> > Patrick
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>