Do you guys think we could sort of extend the particule systems to use
real objects defined in pov's syntax(or maybe somthing like the lights:
a big particule that more or less looks like the real object, and the
object to draw on top of the position?)
This would be interesting to help animations, and also would be better
if you could add some predefined behaviors(like, follow sokine at start,
and only then start using the animation system)

And, uh, do you think shaders could be done in POV-Ray(like in
Renderman)??

Yeah, i know, these two functions would probbly be hard on the system...
For the animation system, you could probably use some kind of
preprocessor, and a good GUI instead of building it inside POV(has any
of you used DreamWeaver? something like the DHTML interface would be a
good way to do the gui, i think)

Hope to get some comments!
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...

Post a reply to this message

pk wrote:

> And, uh, do you think shaders could be done in POV-Ray(like in
> Renderman)?? Hope to get some comments!

It is possible but damn hard - you would need to write an interpreter for
the shader language - maybe RenderMan could lend us their shader
interpretation code :))
under
http://povray.org/links/3D_Programs/POV-Ray_Unofficial_Patches_and_Front_End_Programs/POV-Ray_Patches_v2_2/

There is POVMAN - POV v2.2 patch but it is not available - just a picture of
the results on the page

--
Bye
Pabs

Post a reply to this message

Pabs wrote:
> 
> pk wrote:
> 
> > And, uh, do you think shaders could be done in POV-Ray(like in
> > Renderman)?? Hope to get some comments!
> 
> It is possible but damn hard - you would need to write an interpreter for
> the shader language - maybe RenderMan could lend us their shader
> interpretation code :))

In fact, the required skills to write a shader is about the same
as the skills required to write a new pattern into POV-Ray's core code.
Shaders are compiled code, dynamically linked (like dll's) to
the rendering engine.  So, implementing shaders in POV-Ray wouldn't
be THAT hard (though not easy-easy), but using them would require 
the ability to write C code.

Fabien.

Post a reply to this message

Fabien Mosen wrote:

> Pabs wrote:
> >
> > pk wrote:
> >
> > > And, uh, do you think shaders could be done in POV-Ray(like in
> > > Renderman)?? Hope to get some comments!
> >
> > It is possible but damn hard - you would need to write an interpreter for
> > the shader language - maybe RenderMan could lend us their shader
> > interpretation code :))
>
> In fact, the required skills to write a shader is about the same
> as the skills required to write a new pattern into POV-Ray's core code.

Yes to write a new shader but what about implementing a shader
interpreter/caller in POV-Ray.

> Shaders are compiled code, ???????????????? dynamically linked (like dll's)
> to
> the rendering engine.  So, implementing shaders in POV-Ray wouldn't
> be THAT hard (though not easy-easy), but using them would require
> the ability to write C code.

Does that mean you need a compiler that will generate the actual CPU/machine
code (platform dependant) for the shader or do you have compilation built into
the renderer & it compiles the shader as an initial stage in rendering.

I thought that shaders were interpreted (seems unlikely now that I think about
it - way too slow)

How do shaders work anyhow.?

Does anyone have the zip/tgz/? of that patch that I mentioned.
--
Bye
Pabs

Post a reply to this message

Pabs wrote:
> 
> Fabien Mosen wrote:
> 
> > Pabs wrote:
> > Shaders are compiled code, ???????????????? dynamically linked (like dll's)
> > to
> > the rendering engine.  So, implementing shaders in POV-Ray wouldn't
> > be THAT hard (though not easy-easy), but using them would require
> > the ability to write C code.
> 
> Does that mean you need a compiler that will generate the actual CPU/machine
> code (platform dependant) for the shader or do you have compilation built into
> the renderer & it compiles the shader as an initial stage in rendering.
> 
> I thought that shaders were interpreted (seems unlikely now that I think about
> it - way too slow)
> 
> How do shaders work anyhow.?
> 

I happen to write shader patch for POV-Ray. This patch will have
Renderman shading language compiler for surface shaders, which compiles
it into bytecode and POV-Ray will have stack-based interpreter. I've
almost completed first version, which implements some stuff from RM 3.8
SL (left out is derivative part and support for texture maps, matrixes
(these are left for next version), shadow maps (probably not needed for
RT??)). It has other limitations as well, but quite a number of RM
surface shaders could be used with this patch (e.g. from BMRT distro). I
hope, that within month it will be released (no, this is not promise, it
is hope only ;-)

Compiling shader into machine code and then dynamically linking has
problems, as POV-Ray is supported in multiple platforms and it is hard
to do such thing in portable manner (remember, what happened with
iso-functions in dll-s?), whereas bytecode is hold in ASCII text file
and is compeletely portable. And bytecode is not so very slow either:
for example BMRT got this support lately and by it's documentation it
gave speedup 10-50%, so for non-professionals, who do not have deadline
problems, it should suffice.

> Does anyone have the zip/tgz/? of that patch that I mentioned.
If you are really interested, then this POVMan code for POV-Ray 2.2 is
somewhere in ftp.cdrom.com, under POV-Ray. I got it from there and based
my patch on it. R. Mercier gave me gently permission to use his code.

Post a reply to this message

>Shaders are compiled code, dynamically linked (like dll's) to
>the rendering engine.  So, implementing shaders in POV-Ray wouldn't
>be THAT hard (though not easy-easy), but using them would require
>the ability to write C code.

Also, if you used the .dll approach, it would exclude most of the platforms
that are supported by POV.
HH

Post a reply to this message

Halbert wrote:
> 
> >Shaders are compiled code, dynamically linked (like dll's) to
> >the rendering engine.  So, implementing shaders in POV-Ray wouldn't
> >be THAT hard (though not easy-easy), but using them would require
> >the ability to write C code.
> 
> Also, if you used the .dll approach, it would exclude most of the platforms
> that are supported by POV.
> HH

No, not per se. Most any of today's OSes have something like
dll available (MacOS <= 8 ?). All modern Unices have and
the referred isopatch shared lib ran very well on them.

Actually, the problem is rather: In order to compile shaders from
source to dll/shlib you would need some software that is
often part of development packages only. (Win out of the box
does NOT contain compilers, linkers, preprocessors and such.)
I.e. the average (Win) user would not be able to compile such
shaders. That's where bytecode comes in. Even then re-using
existing tools (cpp) would help a lot.

As to "shaders in pov": Implementation of bytecode interpreters
and source-to-bytecode compilers is one thing. The other thing
is providing everything a shader needs inside pov. Many
params needed by shaders are not available when a shader
is called in pov. Some are, but not in the right place
(i.e. are not passed down the call chain), some are not
existing at all. Not to talk about geometry-changing
displacement shaders.

-Hans-

Post a reply to this message

Cool! Good luck getting it done in a month, Vahur. It sure would give me
something fun to play with when I come back from the pilgrimage to Rome. :)

Post a reply to this message

Hans-Detlev Fink wrote:
> 
> Halbert wrote:
> >
> > >Shaders are compiled code, dynamically linked (like dll's) to
> > >the rendering engine.  So, implementing shaders in POV-Ray wouldn't
> > >be THAT hard (though not easy-easy), but using them would require
> > >the ability to write C code.
> >
> > Also, if you used the .dll approach, it would exclude most of the platforms
> > that are supported by POV.
> > HH
> 
> No, not per se. Most any of today's OSes have something like
> dll available (MacOS <= 8 ?). All modern Unices have and
> the referred isopatch shared lib ran very well on them.
> 
> Actually, the problem is rather: In order to compile shaders from
> source to dll/shlib you would need some software that is
> often part of development packages only. (Win out of the box
> does NOT contain compilers, linkers, preprocessors and such.)
> I.e. the average (Win) user would not be able to compile such
> shaders. That's where bytecode comes in. Even then re-using
> existing tools (cpp) would help a lot.
> 
Yes. 
BTW, does anybody know portable and free cpp (c preprocessor)
implementation/source code? I'd like to add its support to shading
language compiler, then shaders could use include files and #define-s.
I've found one in lcc package and seems like its copyright conditions
allows to distribute it with my patch, so it may be one option.

> As to "shaders in pov": Implementation of bytecode interpreters
> and source-to-bytecode compilers is one thing. The other thing
> is providing everything a shader needs inside pov. Many
> params needed by shaders are not available when a shader
> is called in pov. Some are, but not in the right place
> (i.e. are not passed down the call chain), some are not
> existing at all. 
Yes, I've noticed this. But this is usual problem, when someone wants to
integrate 2 different "systems". So far I  tried to avoid big changes in
POV-Ray to avoid merging problems, as POV-Ray itself (or more correctly,
MegaPOV) is in changing mode with all these patches. But seems like I
can't avoid some global changes (e.g. there is need to have
transformation matrix for shadable (??) object, in order to implement
transformation functions. But POV objects do not have such method, so I
have to add to each pov object according method. )

>Not to talk about geometry-changing
> displacement shaders.
Displacement shaders would be nice, but seems like only viable solution
is tesselation of surfaces into micropolygons in order to displace them.
And implementation of this for each object type will require much of
changes. Easiest would be to add displacement shader support to already
tesselated objects (and triangle meshes).

Post a reply to this message

Vahur Krouverk wrote:
> BTW, does anybody know portable and free cpp (c preprocessor)
> implementation/source code? I'd like to add its support to shading

Do you mean something other than gcc?

dik

Post a reply to this message