In article <41dcb8a3@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> > C is impractical for other reasons...you'd need a C compiler, obviously. 
> 
> Um, well, yes. I was under the impression POV-Ray is written in C 
> already anyway. Indeed, you'd need a C compiler to extend POV-Ray in C. 
> If your implication is that no code written in C can be run on a user's 
> machine that doesn't have a C compiler installed... erm... :-)

No. I'm saying you'll need a compiler to run C source code, such as 
shaders written in C.


> I suspect Tcl already runs on more platforms than POV-Ray, altho I 
> wouldn't guarantee it runs on every platform POV-Ray runs on. I suspect 
> Tcl runs on more platforms than you think it does, tho. ;-)

I'm talking about the C compiler you suggested using for shaders. GCC 
might suffice, if the license allows bundling it like this, but it would 
add several megabytes at minimum to the POV-Ray distribution.


> You'd have to compile it, once per platform. Just like any attribute 
> you'd add to the SDL anyway. You wouldn't need to recompile the base 
> POV-Ray, tho.

But you would still have to compile the shader. It would probably then 
be loaded as a dynamic library by the POV executable, assuming the 
interface for doing so is reasonably easy to port. Tcl might have 
built-in facilities for doing this portably, but it's the first step 
that's hard.


> > A C development environment is a bit heavy to 
> > include along with the raytracer, and is likely to be a huge source of 
> > problems on different configurations.
> 
> I don't need a C development environment to run POV-Ray. I don't 
> understand what point you're trying to make.

Because it has its own custom language for functions, the closest thing 
it currently has to shaders. If you used C for a shader language, you 
would need a C development environment.


> Yes. Except that's already built into Tcl. It's called a "safe 
> interpreter". Been around for about 15 years now. I work with the guys 
> who invented it.

I don't see how that helps the security of the code written in C.


> Well, it's possible I just don't understand what you mean by a "shader". 
> However, what I was *trying* to say was, you can extend the SDL with C 
> if the extension is compute-intensive, and it wouldn't need to be part 
> of the official POV-Ray release, but it wouldn't be an entirely new 
> program either - just an extention.

That's essentially what a shader is. A mini-program used to do texturing 
and lighting calculations for the renderer. (Sometimes other stuff like 
geometry as well.)
They're typically compiled to bytecodes and interpreted. I think the big 
packages do let you load C object code or libraries, but you need the 
development tools...


> Or you can extend it directly in SDL, if the performance is good enough. 
> You could, for example, write Tcl code to import Wings3D files directly. 
> If that was too slow, you'd build an ImportWings.DLL (an ImportWings.SO 
> and etc) to run faster, and write Tcl code that if the DLL isn't there, 
> you fall back to the slower method.

But if Tcl doesn't even have built-in numeric calculations, it would 
probably be difficult to add them in a way that gets good enough 
performance for shaders.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Wed, 05 Jan 2005 21:35:34 -0800, Darren New <dne### [at] sanrrcom> wrote:
> > But you would still have to compile the shader.
>
> I'm not following. Why would I need to compile it myself, any more than 
> I need to compile POV-Ray myself? Why would compiling a shader be harder 
> than compiling POV-Ray is today?

I have a feeling that what Christoph is referencing here is that current
functions engine can be compiled into so called machine code without any
external C/CPP compiler. AFAIK all is required is kind of table for
"translating" function virtual machine codes into cpu codes as (IIRC) it is
done for (some of) Macs.

4.5.1.1.2 Fast Functions
http://www.povray.org/documentation/view/3.6.1/747/

ABX

Post a reply to this message

In article <l6spt0lpe76t20v524bkp5naifi490qfka@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> I have a feeling that what Christoph is referencing here is that current
> functions engine can be compiled into so called machine code without any
> external C/CPP compiler. AFAIK all is required is kind of table for
> "translating" function virtual machine codes into cpu codes as (IIRC) it is
> done for (some of) Macs.
> 
> 4.5.1.1.2 Fast Functions
> http://www.povray.org/documentation/view/3.6.1/747/

No, that's not what I'm referring to. I do know where the 
miscommunication is happening though...see other reply.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On Thu, 06 Jan 2005 06:44:34 -0800, Darren New <dne### [at] sanrrcom> wrote:
> So why would you need a C compiler to do this? That's what I'm not 
> following. Why is it easier to do that on POV-Ray 3.6 than it would be 
> to do on POV-Ray 4.0? Why not just do it the same way as already works?

I do not know what was meant in earlier discussion here but I suppose that
build-in compiler is in POV-Ray 3.6 because POV-Ray 3.6 is between POV-Ray 3
and POV-Ray 4. In other words, I think that's imposssible to introduce all the
changes in single release without releasing anything for years.

ABX

Post a reply to this message

In article <41dcce25$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> I don't need a C compiler to run shaders written in C, any more than I 
> need a C compiler to run POV-Ray written in C.

You do, since shaders are almost never distributed as native machine 
code.


> > I'm talking about the C compiler you suggested using for shaders.  GCC
> > might suffice, if the license allows bundling it like this, but it would 
> > add several megabytes at minimum to the POV-Ray distribution.
> 
> I'm not sure why you wouldn't distribute shaders (or whatever you wanted 
> efficiently) in the same way you distribute POV-Ray now.

Because shaders are written by the users, not the developers. This is 
the point I think you've been missing. Shaders are used when the built 
in primitives are too limited or awkward to accomplish a given job.


> > Because it has its own custom language for functions, the closest thing 
> > it currently has to shaders.
> 
> This has too many typos and pronouns for me to figure out what you're 
> talking about. What's "it"?

"It" is POV-Ray. It supports user-defined functions which are compiled 
into opcodes for a virtual machine, and optional further compilation 
into native machine code. These functions can be used to define 
isosurfaces, patterns, and with a little extra work, pigments. Not quite 
a full-blown shader language, but the closest thing POV-Ray currently 
has.


> > If you used C for a shader language, you 
> > would need a C development environment.
> 
> I'm not sure what a shader language is. I'm not suggesting a shader 
> language, but rather the use of Tcl as the basis for SDL.

Rather than assembling a material out of predefined patterns, the user 
writes a "shader program", a function that computes the resulting color 
for the renderer. Tcl is probably quite unsuitable for this, so you 
would need a separate language just for shaders and similar 
high-performance functions. There isn't any particular reason the entire 
SDL couldn't use the same VM. Some capabilities, such as defining 
objects, would be "low performance" and would be a bad thing to put in a 
shader, but I don't see a definite reason to have separate languages.


> > I don't see how that helps the security of the code written in C.
> 
> I don't know why you're fixated on C.

Because you suggested it as a high-performance alternative to Tcl, for a 
shader language.


> > They're typically compiled to bytecodes and interpreted.
> 
> You mean, like Tcl.

Superficially. What I was trying to point out was the difference from C, 
in that machine-specific forms are rarely distributed widely. You need a 
compiler that supports the platforms, or you need a VM capable of high 
performance FP math. That practically means a custom VM, 


> > But if Tcl doesn't even have built-in numeric calculations, 
> 
> Of course it has numeric calculations built in. I just said the syntax 
> isn't quite as standard as you might want, nor are numeric expressions 
> likely as efficient as a language compiled all the way down to machine code.

Earlier, you said:
> Mind, Tcl isn't really good at math as such, but on the other hand since 
> math isn't technically built into the language, that would probably be 
> pretty easy to improve.

I might have misunderstood this, but I took it to mean that math is 
implemented on top of mechanisms provided by the VM, rather than built 
into the VM. The extra abstraction can be useful, but can really hurt 
performance in floating-point heavy stuff like shaders.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41dd6fb2$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Let's reset a little bit. I'm talking about whether it would be better 
> to base SDL 4.0 on an existing extensible scripting language with 
> ray-tracing primitves added, rather than basing it on a whole new 
> parser/runtime.  (Note: I am not suggesting anything about POV4. Just 
> talking. :-)
> 
> In either case, if the primitves are inadequate and you don't have a 
> precompiled version of the shader, then you're SOL. So maybe I'm missing 
> why shaders even came up in the discussion.

It's a reason why a new parser/runtime could be better than an existing 
one, like your suggestion of Tcl.


> > "It" is POV-Ray. It supports user-defined functions which are compiled 
> > into opcodes for a virtual machine, and optional further compilation 
> > into native machine code. These functions can be used to define 
> > isosurfaces, patterns, and with a little extra work, pigments. Not quite 
> > a full-blown shader language, but the closest thing POV-Ray currently 
> > has.
> 
> OK. And surprisingly enough, this implementation doesn't require a C 
> development environment. So....

POV doesn't currently use a "standard" programming/scripting language 
like Tcl. It uses its own language, and its own VM, designed 
specifically for floating point functions. Isosurfaces would render a 
lot slower if their functions were written in Tcl. They'd be faster if 
they were written in C, but that isn't very practical.


> Actually, I'd expect it to be quite suitable, but relatively slow since 
> it is after all byte-compiled. If you wanted it to be fast, you'd either 
> do something like POV-Ray does now, or you'd write the shader primitve 
> you're interested in in a faster compiled language like C and 
> dynamically load it as needed, or you'd write it in Tcl with possibly an 
> option to look for the already-compiled code and load that if it's 
> available.

We're talking about something that could be a complex function evaluated 
for every ray traced, possibly hundreds of times per pixel...thousands 
of times with antialiasing. Much more with blurred reflection, media 
shaders, and so on, and there's no reason the intersection calculations 
themselves couldn't be done in it for custom shapes. "Relatively slow" 
is too slow. Interpreted languages are barely suitable but practically 
necessary, which is why the POV-Ray function VM has hooks for JIT 
compilation. You really need a language optimized for floating point 
calculations, preferably with optimizations for colors, points, and 
normals.


> The benefit having to do with compiled shaders is the same, regardless 
> of what syntax you use for the SDL. Either you support user-defined 
> shaders in some custom language, or you support them as C libraries, or 
> you don't support them at all, and all three of those are available 
> regardless of the syntax of the language.

But once you have a custom language for shaders, why do you need another 
language like Tcl for the SDL? You could use one language, one VM for 
both purposes. The result is less internal code, and less stuff for 
people to learn.


> > Superficially. What I was trying to point out was the difference from C, 
> > in that machine-specific forms are rarely distributed widely.
> 
> Well, ask yourself why.  It's not like *no* software is widely 
> distributed precompiled. If it's easy to dynamically load shaders on 
> demand, there's no reason they couldn't be precompiled. Imagine an SDL 
> that would do a google search for a precompiled shader for your platform 
> if it ran into a Tcl implementation of that shader....

They can't be precompiled because they are written and distributed by 
users! You can't expect every user that wants to write shaders for 
others to use to have a C development environment with cross-compilers 
for every platform someone might want to use it on.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <41ddac99@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Translating the description of the shader into specific machine code or 
> specific byte codes would be the same amount of work to implement 
> regardless of whether you used Tcl or not to invoke the scripts.

Writing and maintaining both a shader language + VM and a Tcl SDL would 
be more work than writing and maintaining an SDL that also serves as a 
shader language. If you have a decent custom language already in the 
project, I see no reason to add another one.


> I expect the way you would use Tcl in this project is to implement 
> "sphere" in Tcl to output the appropriate bytecodes for the optimized 
> VM. I don't see writing the ray-tracer itself (i.e., the thing that 
> follows the rays and calculates pixel colors) in Tcl to be feasible any 
> more than doing so in SDL is feasible.

But maybe you don't want a plain sphere. Maybe you want a sphere with 
ripples on it. Thus, you need to execute user-defined code, and the 
faster the better.
With an improved custom-purpose SDL, replacing most of the raytracer 
with user-written code would be slower, but perfectly feasible. You 
could even implement your own raytracer, though there would be no reason 
I can think of to do so.


> Basically, you'd use Tcl to build the scene, and then your specific VM 
> to interpret the stream.  Layering, ya know?

But what purpose is there to another layer?


> The language that builds the VM byte stream doesn't have to be 
> especially fast. I mean, heck, POV-Ray 3.x (as far as I understand) 
> actually reparses the source text to do so. Tcl would be faster because 
> after the first time thru the loop, the parsing is byte-compiled.

But not fast enough. Not all VMs are equal. It's byte compiled, so are 
POV functions. However, the POV function VM is built for crunching 
numbers, and is almost certainly much faster at it than Tcl.


> > But once you have a custom language for shaders, why do you need another 
> > language like Tcl for the SDL?
> 
> The "custom language" would be Tcl.

No, the custom language I'm speaking of here is the shader language. 
Tcl's too slow for that.


> > You could use one language, one VM for both purposes.
> 
> Well, are you assuming that a VM needs a custom language to write a 
> compiler for? That may be the miscommunication.

No, of course not. The "custom language" could be essentially a clone of 
Tcl, with floating point and vector optimizations. Then there'd be even 
less reason to use standard Tcl.


> You can expect, however, that there is at least one person who has a 
> compiler for your platform, or POV-Ray wouldn't be running there. The 
> stumbling block isn't that compiled versions don't work for some reason. 

Yes, it is! I can't run x86 machine code on my iBook. Without a 
compiler, I can't run stuff I just wrote in C. Having someone else 
compile stuff for me every time I tweak the code just isn't an option.


> The stumbling block is a lack of distribution facilities where you can 
> find it precompiled. If there's a central place holding shaders, there's 
> a central place where people could contribute executable versions.

No, it isn't. I can't go download a compiled version of a shader I just 
wrote. Again, shaders are written by *users*. They need to be able to 
write the code, then run it. It needs to run as fast as feasible.


> Plus, if the shaders are written to compile down to some VM, the VM 
> code could be either built into POV or could be distributed along 
> with or instead of the source.

That is exactly what is done with many shaders, though it is a bit more 
flexible and useful to distribute the source.


> I mean, Tcl has a whole bunch of executable extensions that are written 
> and distributed by users. It's really not that hard. :-)  And I suspect 
> that POV-Ray doesn't run on *so* many platforms that, say, 6 different 
> executables wouldn't satisfy >95% of the users using it, and the other 
> 5% probably have the development environment anyway.

Requiring people to have a 6-way cross-compiling development environment 
in order to write and distribute a reasonably advanced scene is 
ridiculous. Alternatively, requiring them to have a development 
environment for their own system or know someone who does in order to 
render the scene is equally ridiculous. Interpreted languages are 
practically necessary for useable shader languages. However, even the 
fastest ones are also nearly too slow to be of practical use for that.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Chris B" <c_b### [at] btconnectcom> wrote:

> It is already possible to use VRML to describe a scene (not a POVRay scene).
> VRML has been about since about 1994.
> There is a project working to convert it to an XML base (xVRML) as it was
> originaly based on SGML principles. In fact I think they released an XML
> schema for it way back in 2003.

yes
and the xVRML Project has mad significant strides
since this note was posted...

see:  http://www.xvrml.net/

the spec sections for static scene elements are almost completed
and the sections for dynamics come next

an initial tech-demo viewer application is avail through the above URI

> I think there are probably lots of people on the VRML news groups and in the
> xVRML community that are interested in such a system.

I would agree

> I myself took a brief interest in this before discovering POVRay.

interesting the paths we all follow...
I took the opposite route
shifting my energy from PoV to VRML in 1994
and these past couple of years
focusing on developing an XML-based VR language (xVRML)

> put me off VRML (and the concept of using tagged markup languages for scene
> description in general) is the enourmously verbose manner used to describe
> an object.
> As has already been mentioned, POVRays Scene Description Language provides a
> highly elegant and concise yet flexible way to describe objects.

IMHO: PoV and other static-image-oriented systems
have different target domains and audiences than web-based VR
so I think of this as comparing apples and doughnuts

Constructivist approaches in education include
structuring lessons to "build on prior knowledge"
and we are trying to apply that lesson to xVRML

anyone who can understand HTML code
can learn to understand xVRML in a **very** brief time
because it is deliberately structured to take advantage of
existing understanding of HTML and other tag-based markup languages
already held by new content creators

I have been testing this out this Quarter
at the college where I teach...
I am teaching the same "intro to vr" class
which I have taught for five years now...
the students seem to have
about the same base of prior knowledge as always
and are about as smart as always
and yet this term
I switched to using the current (beta) xVRML version
and to using the current (alpha) tech-demo viewer app ("Carina")
and suddenly I have a class going through the material
at literally twice the rate that classes have done
so over the past 5 years
so I feel there is at least preliminary/anecdotal evidence
that this approach is working effectively

> scenes, and even then I've never seen any VRML scenes that come close to the
> sophistication of some of the newbie POVRay scenes posted on the povray
> newsgroups.

but of course...
the PoV newbies are working to create things which
consist of one rendered frame at a time
and which is not necessarily going to be
downloaded off of the web
while VR scene newbies are working to create things which
people can "fly through" at a decent multi-framerate
and which *are* necessarily going to be
accessed over the Web

different targets and domains

IMHO a lot of people who want to generate
photorealistic raytraced stills
and slowly-constructed animations
can also find a lot of interesting things to do
with lightweight 3D VR
rapidly obtained from the Web
and rapidly rendered as a just-in-time
animation under the control of the user

jeffs
http://www.xvrml.net/

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:

> Obviously POV-Ray SDL is not perfect tool but also obviously it is a lot of
> power already and I very often choose it as simple scripting tool for series
> of simple operations. For example in samples there is a portfolio which easily
> outputs html files with all images rendered. But adding "cool" programming
> features just because they are "cool" is questionable. In spite of all POV-Ray
> is a renderer so let's concentrate on rendering features: types of objects,
> cameras, lights, build-in patterns, antialiasing, HDRI, splines, visual
> effects, radiosity etc, etc. There is so much to do around such features that
> making programming "cool" if you probably have already your favourite
> programming language which you can easily adopt to preparing SDL file is
> wasting of man power (IMO).
>
> ABX


I completly agree, POV-Ray shouldn't become an advanced programming language
like C++ or Java, but it should offer POV-artists a much more easier way of
making complex and realistic scenes. I think concentrating on that is the
only way of making POV more efficient.

I don't want to have to learn C++ before using POV, because POV is good as
it is now, the only thing i want is an easier way to make my scenes look
good. Making the language more complex isn't going to help anyone who's not
interested in the technological details, but wants to make a nice scene.

POV's got enough handy programming-features that i use to make my work
easier (like macro's, loops and defining variables and objects), they're
not to hard to understand and i'd like to keep it that way.

Post a reply to this message

iceqb <nomail@nomail> wrote:
> I completly agree, POV-Ray shouldn't become an advanced programming language
> like C++ or Java, but it should offer POV-artists a much more easier way of
> making complex and realistic scenes.

  One could argue that those two things are actually the same thing.

> I don't want to have to learn C++ before using POV

  A fully-featured object-oriented language does not automatically mean
that you *must* learn *all* the intrinsic complicated details of the
language in order to create scenes. I have always wondered why so many
people seem to think like it does.

  Let me present a comparison, using Windows:

  Does a regular user, who just wants to surf the net and read his email,
have to learn how to edit the Windows registry?
  The answer is naturally: No.

  Is it *bad* that Windows includes the means to edit the registry?
  Of course not. Those who want to edit it can do so. Is that bad?

  The fact that a feature *exists* does not mean that you *must* even
know about its existence in order to use the program.

  If fully object-oriented features are added to the scene description
language, so what? It doesn't necessarily mean that you must learn to
use them in order to create scenes.

  You have to realize that there are two kinds of POV-Ray users: Artists
and developers.
  The idea with enhancing the language is that developers have better
better tools to create easy-to-use libraries for the artists to use.

  Wouldn't you like it if you could just write 'import("scene.3ds")' and
magically the 3ds file is imported and rendered?
  If the SDL is enhanced enough and if some developer creates such a
library, then you can do exactly that, ie. import 3D-Studio files with
a one-liner (without even having to know that something called
"object-oriented programming" even exists).

  So I more or less completely disagree with you: POV-Ray *needs* and
would greatly benefit from a fully-featured programming language.

-- 

                                                          - Warp

Post a reply to this message