hello,

I've recently started playing with BMRT and now I wonder, is there any
technical reason (as opposed to things like lack of time or manpower) why the
texturing in povray uses hardcoded procedures instead of something like the
RenderMan shaders? they seem a lot more powerful, and it seems better design
as well.

am I missing something?

Lodewijk

Post a reply to this message

Lodewijk Voge wrote:
> 
> hello,
> 
> I've recently started playing with BMRT and now I wonder, is there any
> technical reason (as opposed to things like lack of time or manpower) why the
> texturing in povray uses hardcoded procedures instead of something like the
> RenderMan shaders? they seem a lot more powerful, and it seems better design
> as well.
> 
> am I missing something?
> 
> Lodewijk

I think, that hardcoded procedures are faster.

Post a reply to this message

Disnel <Dis### [at] linuxitamcascz> wrote:

  >> I've recently started playing with BMRT and now I wonder, is there any
  >> technical reason (as opposed to things like lack of time or manpower)
  >> why the texturing in povray uses hardcoded procedures instead of
  >> something like the RenderMan shaders?
  
  > I think, that hardcoded procedures are faster.

faster than interpreted RenderMan shaders like BMRT uses, yes. not
significantly faster than shaders (in whatever language would be most
convenient) compiled to dynamically linkable objects that the povray
executable would link in on demand.

Post a reply to this message

Lodewijk Voge wrote:
> 
> Disnel <Dis### [at] linuxitamcascz> wrote:
> 
> >> I've recently started playing with BMRT and now I wonder, is there any
> >> technical reason (as opposed to things like lack of time or manpower)
> >> why the texturing in povray uses hardcoded procedures instead of
> >> something like the RenderMan shaders?
> 
> > I think, that hardcoded procedures are faster.
> 
> faster than interpreted RenderMan shaders like BMRT uses, yes. not
> significantly faster than shaders (in whatever language would be most
> convenient) compiled to dynamically linkable objects that the povray
> executable would link in on demand.

This is true.  Unfortunately, one of the most important aspects of POV is
its multi-platform capabilities.  For the record, the Isosurface patch
and the SuperPatch (the SuperPatch does have the isosurface patch in it,
right?) do allow user-defined functions for patterns.  This is not quite
as flexible as RenderMan shaders, but it's a start.  And you can use
dynamic libraries in windows and unix.  But the two OS's don't use the same
libraries, and you can't use them on any other platform.  :-(

-Nathan

Post a reply to this message

On Wed, 16 Dec 1998 00:24:05 -0500, Nathan Kopp <Nat### [at] Koppcom> wrote:
>This is true.  Unfortunately, one of the most important aspects of POV is
>its multi-platform capabilities.  For the record, the Isosurface patch
>and the SuperPatch (the SuperPatch does have the isosurface patch in it,
>right?) do allow user-defined functions for patterns.  

Yes, it is compiled into the superpatch.  In fact, it was in a sense the
first patch to be added to the superpatch, oh so long ago.

>And you can use
>dynamic libraries in windows and unix.  But the two OS's don't use the same
>libraries, and you can't use them on any other platform.  :-(

Correct, and for that reason I've been told that if the isosurface patch ever
does make it into the official version, it'll probably be without the dynamic
linking, even on the platforms that support it.

Another of the things on my "difficult-to-impossible" list of things I'd like
to do someday is a bytecode compiler (possibly with OS-specific hooks for a 
JIT compiler) to handle a (hopefully large) subset of the Renderman Shading 
Language, all without dynamic linking.  If someone's written a JIT compiler
for your platform, you could be looking at the speed of a hardcoded texture
even on platforms that don't support dynamic linking.  If not, or if you're 
on some B&D platform that doesn't allow self-modifying code, you'll lose 
some speed but no functionality.

Post a reply to this message

I personally don't think it convient using RenderMan type shader in POV,
because you have to compile it and then compile the rib file containing the
texture before you can see it.  There is a extra step involved.

Lodewijk Voge wrote in message ...
>hello,
>
>I've recently started playing with BMRT and now I wonder, is there any
>technical reason (as opposed to things like lack of time or manpower) why
the
>texturing in povray uses hardcoded procedures instead of something like the
>RenderMan shaders? they seem a lot more powerful, and it seems better
design
>as well.
>
>am I missing something?
>
>Lodewijk

Post a reply to this message

How wrote:
> 
> I personally don't think it convient using RenderMan type shader in POV,
> because you have to compile it and then compile the rib file containing the
> texture before you can see it.  There is a extra step involved.
> 
> Lodewijk Voge wrote in message ...
> >hello,
> >
> >I've recently started playing with BMRT and now I wonder, is there any
> >technical reason (as opposed to things like lack of time or manpower) why
> the
> >texturing in povray uses hardcoded procedures instead of something like the
> >RenderMan shaders? they seem a lot more powerful, and it seems better
> design
> >as well.
> >
> >am I missing something?

I don't think you're wrong.  My reply is why not have both?  The
hardcoding can save on render times if all you want are simple variancew
along the Z axis or a radial change, but being able to include one's own
designs is very very nice indeed.

As to the compiling process used by BMRT- there is NO reason this needs
to be, the renderer should be able to parse it's own darn procedurals-
perhaps a memory sacrifice in order to pre-compile before execution
would work if on-the-fly would be too slow.  At any rate one could write
a simple util to automate all this anyway- I'll take all the power I can
get in my textures! :o)

> >Lodewijk

-- 
Stuff for POLYRAY, some raytraced images, and
DTA can be found at:
http://www.europa.ccom/~dearmad

Post a reply to this message

How <s-w### [at] ihugconz> wrote:

(in reply to a very old message ;)

  > I personally don't think it convient using RenderMan type shader in POV,
  > because you have to compile it and then compile the rib file containing the
  > texture before you can see it.  There is a extra step involved.

ofcourse, but there's things that are impossible or very hard to do with the
current setup that are more easily done with procedures. 

it's good that you brought this up again, because I've recently been
involving myself in Python, a very nice scripting language whose interpreter
also happens to be very easily integrated in C programs. it'd be slow, but
I think it can be plugged in with relatively little effort.
(http://www.python.org/ for interested readers)

I'll try and remember this next time I feel a hack-binge coming on ;)

Post a reply to this message