Question: compiling my Renderman program
Adrian D'Alimonte
through the book.
It says it is written in C, and when I try to compile it using Turbo C,
it says there is a function
error in line 13 (I am quoting the first example program in the book),
and that main( ) is supposed
to have some sort of return? The only thing i can think of is that
maybe it is not leading my ri.h correctly..
or libribout.lib? Sorry if this seems amateur, i know very litlle about
C. :)
I am using BMRT, on win95, compiling with Turbo C. Thanks for any help!
Adrian
Manuel Alducin
with Visual C++ and it has C++ linkage. As far as the error C++ requires
that you specify the type of the return value and parameters, so you must
actually right main as:
void main()
{
// the program goes here
}
There is an example included in the distribution. Besides that, get a good C
and C++ book. Also make sure your file is saved with a cpp extension, instead
of c extension, to tell the compiler it's C++. Don't worry, all those C
programs will compile also as C++ programs (with very minor modifications).
Adrian D'Alimonte <cu...@geocities.com> wrote:
: Hi there, I just receieved my Renderman Companion, and trying to work
-------------------------------------------------------------------
Manuel Alducin
mald...@acm.org
Computer Graphics and Multimedia
The George Washington University
-------------------------------------------------------------------
manuel...@bbc.co.uk
> programs will compile also as C++ programs (with very minor modifications).
just a sligh pang of interrogation: C is a subset of C++. compiling C
with a C++ compiler should not require -any- modification ???
Manu.
T. Burge
>with a C++ compiler should not require -any- modification ???
But that isn't true though. Take for example exporting a function from
a file compiled with a C++ compiler. If you look at headers such as the
X lib headers you'll see code setup with extern "C". For example from a
header file of mine:
#if defined(__cplusplus) || defined(c_plusplus)
extern "C" {
#endif
extern RtObjectHandle RiObjectBegin( void );
#if defined(__cplusplus) || defined(c_plusplus)
}
#endif
There are other differences as well. This is just one that I think
everyone writing a library and public header runs into.
T. Burge
P.S. I haven't been following the thread here, I was just referring to
the one inquiry above.
Manuel Alducin
C++ have chaged this. For example in C++, prototyping functions is required,
and in C is optional (though most compilers will complain). Also in C++ if
you have a function like f() it means it is an empty parameter list (the same
as using f(void)) but in C it means nothing is said about the parameters.
In C if you don't return a value (for a function that is declared to
return one) garabage is usually returned, but in C++ you must have a return
statement. Also C defaults to returning an int if no value is returned but
in C++ there is no default, you must explicitly declare a return type.
Most of these a very minor and probably only will affect if you are compiling
old programs (like the ones in the Companion) or use old C syntax, mainly
the declaration of functions. Although I haven't used Turbo C++ in a long
(very long) time and I don't know all about Visual C++ so some issues might
be mute. I remember that in Borland C++ you could tell the compiler to accept
K&R syntax and what types of warnings you get.
manuel...@bbc.co.uk wrote:
:> of c extension, to tell the compiler it's C++. Don't worry, all those C
:> programs will compile also as C++ programs (with very minor modifications).
: just a sligh pang of interrogation: C is a subset of C++. compiling C
: with a C++ compiler should not require -any- modification ???
: Manu.
manuel...@bbc.co.uk
> a file compiled with a C++ compiler. If you look at headers such as the
> X lib headers you'll see code setup with extern "C". For example from a
the statement extern "C" is only required at the linking stage to make C
object files compatible with C++ objects so that there is no name
collisions. my statement was more like: what would prevent you from
renaming a .c file in .cc and recompile your entire application as C++ ?
> There are other differences as well. This is just one that I think
> everyone writing a library and public header runs into.
point granted, but if the library header is written properly, you
shouldn't have any problem (in fact all you should have to do is add the
#ifndef you just quoted).
Manu.
Larry Gritz
>the statement extern "C" is only required at the linking stage to make C
>object files compatible with C++ objects so that there is no name
>collisions. my statement was more like: what would prevent you from
>renaming a .c file in .cc and recompile your entire application as C++ ?
Variables, functions, or struct fields named "new", "delete", "friend",
or "class".
-- lg
--
Larry Gritz Pixar Animation Studios
l...@pixar.com Richmond, CA
Michael B. Johnson
>
> the statement extern "C" is only required at the linking stage to make C
> object files compatible with C++ objects so that there is no name
> collisions. my statement was more like: what would prevent you from
> renaming a .c file in .cc and recompile your entire application as C++ ?
In my experience, all ANSI C code I write compiles just fine if I treat it as
C++.
Sorry about the hassle of having to compile RenderMan apps as C++ when linking
with libribout.lib on Win32 - that's my fault.
--
--> Michael B. Johnson, SMVS, PhD -- wa...@pixar.com
--> Media Arts Technologist, Pixar Animation Studios (East'of Office)
--> alumnus, MIT Media Lab, Computer Graphics & Animation Group
--> http://www.media.mit.edu/~wave
manuel...@bbc.co.uk
> or "class".
that would be from C++ to C... other way round.
Manu.
l...@pixar.com
No. If you have a C program that uses these as names of variables
(you'd be surprised how many people use 'new' or 'class' as variable
names in C programs), then you try to compile that file with a C++
compiler, it will issue errors. Those are reserved words in C++, but
not in C.
-- lg
--
Larry Gritz Pixar Animation Studios
l...@pixar.com Richmond, CA
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
T. Burge
"friend",
>> or "class".
>
>that would be from C++ to C... other way round.
It is the C to C++ porting direction that causes worries about reserved
words such as "class". C code using C++ reserved words in structures or
variables will not compile with a C++ compiler. For example there is a
X Windows structure that is ifdef'ed for C++ to use an alternate name
for a structure field named "class". The alternate name was added
because "class" was used when it was not considered a reserved word, but
it is a reserved word in C++.
But at this point isn't this thread getting away from a RenderMan
related topic -- sorry I don't mean to try to cut the thread here, but I
just like to read more on things such as fresnel and noise. Or maybe an
interesting point about the spec such as one I read a while back asking
why the spec states that a "unique 3x3 homogeneous matrix" can be used
to implement RiTextureCoordinates() when folks actually just use
bilinear interpolation. I liked the way Rick explored and pointed out
issues regarding an answer to that question. It was just an interesting
question that one of the folks here could give neat aspect to in an
answer for, especially if they were involved in writing the spec.
Did RiSkew() come from the Faux and Pratt book? I never did get an
answer on that bit of trivia on RMan history. After all, it does match
rather closely to the book. For example, NuPatch is based off the Pex
library's NURB surface interface and was implemented after the spec was
released. It was said that it would have been done differently to
neaten up the way the trim curves were described had they known.
Does anyone want to publish their own DSO showing use of level of
detail? Seems to me that if you include the given screen area as a part
of the blind structure given to a child procedural, you can tell how
fast you are reducing the screen area as you subdivide. If you are not
reducing the screen area then you can change to the RenderMan
Companion's technique of a MAXLEVEL counter -- just an off hand thought
I had once.
How about a question such as why PRMan 3.8 subdiv surfaces don't support
"Pw" -- not that I'm complaining since most designers do avoid using
weights other than 1.0 anyway. So I don't think that it will be a
missed feature. It's just that in an article in CGW it was stated that
DeRose was talking with CAD software companies originally, who happen to
like being able to do such things as perfect mathematical circles --
even though, as I said, designers do infact avoid odd weight values so
they can move their data between packages.
Also if you place certain restrictions on the polygon hull defining the
surface (restrictions that I don't think would really be noticeable to a
user) wouldn't triangle patches be another method for getting the same
nice properties as subdiv surfaces? Not that I'm knocking subdivs, just
that you don't hear as much about triangle patches anymore. Although
there is that new Digimation plugin (written by -- if I remember
correctly -- a prof from MIT), which I'm told uses triangle patches.
Sorry, just me rambling off some thoughts I had.
T. Burge
Rick LaMont
T. Burge <burge@NO_JUNKMAIL.apple.com> wrote:
> I read a while back asking why the spec states that a "unique 3x3
> homogeneous matrix" can be used to implement RiTextureCoordinates()
> when folks actually just use bilinear interpolation. I liked the
> way Rick explored and pointed out issues regarding an answer to
> that question.
Thanks, Ted. That article was originally posted to the RenderDotC
mailing list. Here's a reprint for those who are interested:
Okay, so most of us have a vague understanding that we can use
RiTextureCoordinates() to specify what s/t coordinates we want at
the corners of our patches and quadrics. Polygons are unaffected,
but what about NURBS? NURBS aren't always defined over the unit
square like patches and quadrics. On NURBS, u and v range from umin
to umax and vmin to vmax, respectively. How does RiTextureCoordinates()
affect parts of the u/v plane outside of the unit square?
RiTextureCoordinates() defines a mapping from u/v (parameter space) to
s/t (texture space):
s = f(u, v, s1, t1, s2, t2, s3, t3, s4, t4)
t = g(u, v, s1, t1, s2, t2, s3, t3, s4, t4)
By default, the mapping is the identity (s = u and t = v). About
RiTextureCoordinates() and the details of the mapping, the RenderMan
spec says:
> The texture coordinates at each corner of this unit square are given by
> providing a corresponding set of (s,t) values. This correspondence
> uniquely defines a 3x3 homogeneous two-dimensional mapping from parameter
> space to texture space.
Taking that statement at face value, I set up the algebra to find that
3x3 matrix. This 3x3 matrix will translate 2D homogeneous points of the
form [u v 1] to [x y w]. Dividing through by w will yield s and t, s = x/w
and t = y/w.
The unknowns are the 9 elements of matrix A:
[a00 a01 a02]
[a10 a11 a12]
[a20 a21 a22]
The knowns are the 8 parameters to RiTextureCoordinates():
s1, t1, s2, t2, s3, t3, s4, t4
Projecting the four corners of the unit square from u/v to s/t:
[0 0 1] A = [x1 y1 w1]: s1 = x1/w1, t1 = y1/w1
[1 0 1] A = [x2 y2 w2]: s2 = x2/w2, t2 = y2/w2
[0 1 1] A = [x3 y3 w3]: s3 = x3/w3, t3 = y3/w3
[1 1 1] A = [x4 y4 w4]: s4 = x4/w4, t4 = y4/w4
The actual values of the x, y, and w variables come from multiplying out
the A matrix on the left hand side of the equations above. Substituting:
s1 = a20 / a22
t1 = a21 / a22
s2 = (a00 + a20) / (a02 + a22)
t2 = (a01 + a21) / (a02 + a22)
s3 = (a10 + a20) / (a12 + a22)
t3 = (a11 + a21) / (a12 + a22)
s4 = (a00 + a10 + a20) / (a02 + a12 + a22)
t4 = (a01 + a11 + a21) / (a02 + a12 + a22)
That's 8 equations and 9 unknowns: an underdetermined system. One thing it
won't be is "unique" like the spec said. It turns out that there are an
infinite number of solutions, but all are scalar multiples of each other.
Without loss of generality, let a22 = 1 and solve for the other 8 unknowns.
Cutting to the chase, here's the solution in C:
float t1mt2 = t1 - t2;
float t1mt3 = t1 - t3;
float t1mt4 = t1 - t4;
float t2mt3 = t2 - t3;
float t2mt4 = t2 - t4;
float t3mt4 = t3 - t4;
float den = s2 * t3mt4 - s3 * t2mt4 + s4 * t2mt3;
a00 = (s1 * (s3 * t2mt4 - s4 * t2mt3) -
s2 * (s3 * t1mt4 - s4 * t1mt3)) / den;
a10 = (s3 * (s2 * t1mt4 - s4 * t1mt2) -
s1 * (s2 * t3mt4 + s4 * t2mt3)) / den;
a01 = ((s1 * t2 - s2 * t1) * t3mt4 + (s4 * t3 - s3 * t4) * t1mt2) / den;
a11 = ((s3 * t1 - s1 * t3) * t2mt4 + (s2 * t4 - s4 * t2) * t1mt3) / den;
a02 = ((s1 - s2) * t3mt4 + (s4 - s3) * t1mt2) / den;
a12 = ((s3 - s1) * t2mt4 + (s2 - s4) * t1mt3) / den;
a20 = s1;
a21 = t1;
a22 = 1;
This matrix satisfies the 8 constraints. Because it's an affine
transformation, it preserves straight lines but not the angles between
them (is that correct, Ted?) However, it runs into singularities
when den = 0, for example at:
RiTextureCoordinates(0, 0, 1, 0, 0, 1, 0.5, 0.5)
Do any RenderMan implementations do it this way? None that I know of.
The typical solution is simple bilinear interpolation:
s = bilerp(u, v, s1, s2, s3, s4);
t = bilerp(u, v, t1, t2, t3, t4);
Where bilerp is defined as:
float lerp(float u, float min, float max)
{ return min + u * (max - min); }
float bilerp(float u, float v, float x1, float x2, float x3, float x4)
{ return lerp(v, lerp(u, x1, x2), lerp(u, x3, x4)); }
This satisfies the 8 constraints, avoids singularities, but does not
preserve straight lines. Textures come out warped unless the four s/t
points describe a rectangle in texture space.
Why did the spec do all that handwaving about a "unique, 3x3, homogeneous,
..." when everybody uses bilinear interpolation anyway? Did an old version
of PRMan do it the other way? Did the writers of the spec mistakenly think
that bilinear interpolation was equivalent to a matrix multiply?
Rick LaMont
Dot C Software, Inc.
http://www.dotcsw.com/
Michael B. Johnson
manuel...@bbc.co.uk wrote:
> > Variables, functions, or struct fields named "new", "delete", "friend",
> > or "class".
>
> that would be from C++ to C... other way round.
>
>
No, Larry's got it right. Your question was
>my statement was more like: what would prevent you from
>renaming a .c file in .cc and recompile your entire application as C++ ?
if you had aC program:
int
main()
{
int new, delete, friend;
float class;
new = 1;
delete = 2;
friend = 0;
class = (new/delete) + friend;
return (int)class;
}
would be a perfectly acceptable (albeit nonsensical) C program, while any and
every C++ compiler would have a complete fit (i.e. SGI's CC gives 11 errors).
Tom Duff
> answer on that bit of trivia on RMan history. After all, it does match
> rather closely to the book.
Pat Hanrahan designed RI (obviously with a lot of input from other
people.)
I asked him about RiSkew the last time the question came up.
He said that he couldn't remember specifically taking the
details from Faux & Pratt. Of course, he knew the book --
it was the standard reference at the time on geometry for CAD,
so their formulation would likely have been near the surface
in his mind.
--
Tom Duff. I love California. I practically grew up in Phoenix.
Steve Demlow
> How about a question such as why PRMan 3.8 subdiv surfaces don't support
> "Pw" -- not that I'm complaining since most designers do avoid using
> weights other than 1.0 anyway. So I don't think that it will be a
> missed feature. It's just that in an article in CGW it was stated that
> DeRose was talking with CAD software companies originally, who happen to
> like being able to do such things as perfect mathematical circles --
DeRose said the same thing in a talk here last spring, and prompted the same
question in my mind. We moved from Beziers to NURBS for our CAD-like
applications (mesh generation, etc.), and subdivision surfaces are an
alternative worth investigating but would need to have the same generality.
The Sederberg et al. paper in this year's SIGGRAPH Proceedings is a good
step, but forces rethinking of some of the other subdivision surfaces
literature.
Anyway, insider insights on this would be appreciated, e.g observations on
any non-uniform/rational schemes that were considered/implemented in
addition to the scheme in PRMan 3.8.
Steve
--
Steve Demlow -- dem...@networkcs.com (612) 626-8075 (voice)
AHPCRC Graphics and Visualization Support (612) 626-1596 (fax)
Network Computing Services, Inc. (NetworkCS) Minneapolis, MN