POVRay 101: A Beginner's Guide

[Crayons]

Part 1

After some various responses from people about POVray along the lines of "oh, I looked at that once but..." and "I don't do programming..." and so on, I have decided to attempt a Tutorial.

As an introduction before you waste time here...
POVray is a Free 3D Rendering Tool and appears to be unique in that it is solely Text based. I like that, which is odd, because usually I'm all in favour of GUI type tools.
In terms of capability, POVRay is really up there amongst all the best rendering tools, which cost m-o-n-e-y, usually. So you won't be disappointed with any results you get, if you explore the thing sufficiently.
For me, it also has the added benefit of including a number of basic software commands so you can "run" it like code, and let it create stuff through randomness, for example. I haven't worked out how one would do that with a GUI system to the same extent.

Anyway, since it is rather peculiar, and not widely used amongst this community (perhaps for valid reasons) I thought I'd start a beginner's tutorial illustrating some of the basics. It may be that those "valid reasons" have less weight than you think!
Have a play - it won't cost you m-o-n-e-y, only a bit of time.

tutorial 01.pdf

Please feel free to comment or correct anything! feedback is always welcome!

[Redrobes]

This is very cool and I would like to thank you for putting this together. I am a coder and I feel intimidated by POVRay. I know I shouldn't but it seems to me that you need something interactive when making objects. I always thought that you were using something interactive to build it with and then using POVRay as the renderer to describe the scene and put all the objects into it. But if your doing them all by text code then that is quite something.

I dont think POVRay is unique at all being a text language for rendering. Most of the high end stuff does it this way but uses a GUI on top to make the stuff and build it for you. I think Renderman and Gelato are both like this. I also think that even Blender under the hood is kind of like this too. Its certainly trying to build some kind of XML description of the scene. As far as I can tell, the big studios use something like Maya / Alias to build the scene and then renderman as the scene description language then its sent to the render farm to get generated. So learning POVRay is probably a good idea if you want to make a film as it is done in that same kind of manner.

But I would still like to know how to build models in some GUI based thing before sending it to POVRay to render. You ideas about the auto generating towns are a good idea to do in POVRay since you can make a program or script to generate the scene text and then let the engine render it out. You don't have to get involved with the rendering at all. Its like the 3D equivalent of ImageMagick. So what I would like to know is, if you are building something complex, can you get some kind of feedback or preview of what your doing before letting it render the whole thing out ? A lot of what I build is moderately free form and you drag points out and move it here and there by eye. You cant do it with numbers. Just as an instant example, I was making a pair of sunglasses the other day. What process would you go through to make these in POVRay or is it just not geared up for this kind of thing ?

[Crayons]

I'd have to say that I would normally agree with you about having a GUI for something that makes 3D objects. In many ways, I do that manually with POV by doing a lot of quick renders and coding so that all the placement work is done at a "low res" setting. In essence this is what a graphical front end does for you. All the hi powered rendering effects are simply not shown by the front end for the same obvious reasons.

I suspect that my Hardware Engineering background makes me prone to wanting complete control of the situation. Pushing 3D wire representations "loosely" where they should go isn't quite control enough for me. I know you can type the numbers into the relevant dialogues but I do that now, in text.
In reality though, I think it comes down to "visualization". If I'm looking at a GUI "3D view" of a scene, I'm still only seeing a 2D projection of it. I find myself pushing something into place only to discover that it is, in fact, 10 feet behind where I thought it was and I've just been seeing it wrong! If you start from the premise that all your "stuff" has coordinates you generated/calculated then your degree of control is next to complete. Looking at my little train, I have no doubt it would have been a nightmare, for me, using a GUI !
My "GUI" was essentially "in my head" - I have learned to visualize 3D mentally. Well, most of the time!

There is a front end for POVRay you might try, called Moray, which POVray have taken control of and is available there. I tried it a while back after I'd been working purely in POVRay and didn't like it.

Your glasses example is a good one. POVray is not geared up for this sort of thing directly as far as I've seen, but I feel sure there's some expert out there who'd say different. The issue here is basically one of primitives vs meshes and that looks like something to do with a mesh, whatever tool you use. As far as I've seen, POVRay itself does not support creating/editing meshes, but can accept all sorts from elsewhere. Just try searching for converters and they usually pop up. Since I like free stuff on principle I used jpatch when I needed some "odd" shapes for my train.

All that said, and I agree with what you've said, the use of primitives is fine for the sort of stuff people would want to make here for mapping purposes, I think. Coupled with height_fields, you can pretty much do whatever you like. Couple that with the simplicity of cut and pasting bits and bobs around your different designs and the include file capabilities - all done in something as transparent as text, well, WYSIWYG. I don't find myself fighting some GUI trying to make it do something I know it ought to be able to do, I just can't make it do it!!! Aaargh!

As a final point. I have used POVray language elements more since I joined this forum, inspired by comments ! If you look at my Tin Man competition entry, I coded in leaves blown in swathes over the floor. I did this using a "height_field" in a weird way. I had a black image I sprayed with white dots using Paintshop, then wrote a routine that scanned this pseudo-height_field for all the "high points" and plotted a simple 7 sided flat leaf at each point on the render, after randomizing its rotation and adjusting it's height to the actual height_field. Is there a GUI renderer that can do that, for 10,000 leaves? It was fun anyway!

[Redrobes]

I am with you here. There is definitely a place for this app. I made my sci-fi map with image magick which is a 2D text based image scripting tool much like this. I did the millions of random stars in that by using a simple script to whoop them all up. I agree, like leaves I would never have been able to do that manually. I think, therefore, that this app is another one of those things thats a useful tool in the box but is not the all encompassing tool of choice. As such we should all have a go with it and see what we can use it for. I think I am still on the hunt for a really good intuitive 3D modeller tool to complement this tho.

I would also suggest that you have a pop at Perl, Python, Ruby, Lua or similar. Those script languages can churn out text so easily and make writing these scene description files much easier. Perl + ImageMagick is really cool and can seriously make a difficult problem easy so it would be no different with this too. There is a chap on here (isomage ?) too who uses one of the languages to make automated star charts using SVG code in a browser too. What you could do with those + a 3D renderer would be amazing. I guess thats essentially what your town generator is tho isn't it.

[Midgardsormr]

I dont think POVRay is unique at all being a text language for rendering. Most of the high end stuff does it this way but uses a GUI on top to make the stuff and build it for you. I think Renderman and Gelato are both like this. I also think that even Blender under the hood is kind of like this too. Its certainly trying to build some kind of XML description of the scene. As far as I can tell, the big studios use something like Maya / Alias to build the scene and then renderman as the scene description language then its sent to the render farm to get generated. So learning POVRay is probably a good idea if you want to make a film as it is done in that same kind of manner.

If you were so inclined, you could build a scene in Maya entirely in MEL (Maya Embedded Language) or even Python. Every command issued through the GUI appears in the script editor as code as you go along, and there have been a few times where I've just typed in the command I wanted rather than trying to remember which menu it was in. Most of the time, though, the script editor is used to easily automate frequently used tasks and to create expressions that control animated properties. I've never used Renderman, but I use Mental Ray quite a bit. If they're similar, then I'd guess not many artists would send a Maya script directly to the renderer and try to write the shaders there. Rather, they'd be likely to use a plug-in to the GUI that allows them to construct the shader visually.

That's not to say that some of the old-school uber-geeks (i.e. pipeline TDs) don't do things that way, but it's quite rare.

Anyway, thanks for the tutorial. I don't have time to read it right now, but I'll definitely put it on the front-burner for tomorrow!

[Redrobes]

My understanding was that the MEL script was a Maya specific automation script and has significance only to Maya. I believe that Maya can directly output Renderman files tho which I believe are entirely different and are the actual scene and shader descriptions. The PRMan (actual renderman app) takes the scene description files and then can make the visual image from them. I dont think there is any possibility of sending MEL scripts directly to the renderer.

So in a far removed sense, POVRay is like PRMan. My scant knowledge of Mental Rays is that its similar and has a data base where you can feed it similar files to set up the database. The files have an extension of .mi and are mental rays scene description language files. How close they are to renderman I dont know, but the same kind of thing happens where the app takes the database and renders the scene from it. Whether in PRMan you have the whole database as a set of renderman files or it too has a distinct database loaded from the files I have no idea.

So what Crayons is doing is like programming the scene directly in the scene description language and sending it to the renderer. It can be done but I think most people would use a GUI and let a 3D app do the hard work of all those numbers and treat the POVRay file as a mere intermediary. Of course knowing the internals of whats going on is a definite plus, and if you are going to script up an automated tool like the city builder then this is the right way to go. The script (Perl, Python, Java, etc) that is used to automate building the POVRay file is more like the MEL bit of Maya. Instead of using a Perl interpreter, Python interpreter or Java machine, you have Maya which also happens to be a script interpreter that has oodles of 3D capability and naturally much more capable. But the large increase in capabilities are the only difference between this and Hollywood - the fundamental process is the same.

[Vandy]

Hi, All.

Just wanted to let you know that I've created a link for Crayons tutorial. You can find it in the Tutorials in PDF Format thread in the Tutorials/How-To Forum.

The link is located on Page 1, in the "POVRay-Related Tutorials" section of Post 2.

Enjoy.

Regards,

Vandy

[Crayons]

@Vandy - thanks! (I think!) That kinda puts the pressure on getting more done! I'll get on it.

@ Midgardsormr & Redrobes - Firstly, the Tutorial really is supposed to be targeted at Beginners so will doubtless be rather mundane for experienced modellers like yourself! I would also say that I wouldn't normally hold my coding up as a "good standard" - I tend to be a tad slipshod! However, it should illustrate the basics of the tool - I hope.
I've not really tried any other render tools - in depth. I usually get frightened off by the GUI. That's not to say that I dislike GUI's in general, far from it. I think POVRay struck a note with me because by experience and training I'm a hardware engineer - there are similarities in approach to POV and VHDL that I used to write. In both of these there is no overall "order", especially. All commands in VHDL can be considered to run siiimultaneously rather than consecutively, in POV most of what happens is timne independant of other commands - with obvious exceptions.
My software experience is more in assemblers and (as mentioned elsewhere) ye olde BASIC and ALGOL of yore. What I hope to illustrate in the next Part of the Tutorial is the seamless inclusion of "basic" consecutive software commands into what is essentially code structure where seqentialism is largely irrelevant.

I'll get on with Part 2 and then you can judge better what I mean, I hope.

[Crayons]

OK, this is Part 2 of my POVray Tutorial.
Remember, it is a "beginners" guide, hopefully in all aspects, so some of the "softwarey" bits might be a bit laboured for some? Well, all of it might be really!

tutorial 02.pdf

[jtougas]

These are really great. I have NO experience coding anything and these tutorials are really making me want to have a go.