July 2010 Entry : The Solur Nexedifice of Kharaghan

[RobA]

Absolutely. What it can't actuallly do is render a real isometric view. You can simulate it reasonably well by standing the camera off a long distance and cutting down its angle of view which is what I did in an earlier WIP view.

I though POV had an isometric modifier for its camera....

(checking...)

Yep - orthographic keyword:

2.3.1.2.2 Orthographic projection

The orthographic camera offers two modes of operation:

The pure orthographic projection. This projection uses parallel camera rays to create an image of the scene. The area of view is determined by the lengths of the right and up vectors. One of these has to be specified, they are not taken from the default camera. If omitted the second method of the camera is used.

If, in a perspective camera, you replace the perspective keyword by orthographic and leave all other parameters the same, you will get an orthographic view with the same image area, i.e. the size of the image is the same. The same can be achieved by adding the angle keyword to an orthographic camera. A value for the angle is optional. So this second mode is active if no up and right are within the camera statement, or when the angle keyword is within the camera statement.

You should be aware though that the visible parts of the scene change when switching from perspective to orthographic view. As long as all objects of interest are near the look_at point they will be still visible if the orthographic camera is used. Objects farther away may get out of view while nearer objects will stay in view.

If objects are too close to the camera location they may disappear. Too close here means, behind the orthographic camera projection plane (the plane that goes through the look_at point).

-Rob A>

[Crayons]

I though POV had an isometric modifier for its camera....

(checking...)

Yep - orthographic keyword:

-Rob A>

Crikey! Thanks Rob! There's me searching Help for "isometric" all this time! Why can't mathematicians just have one word for something! I imagine there's some subtle difference between "orthographic" and "isometric" but... (no explanations please!!!I will consider my life complete without such knowledge!)
I'll give it a go.

[cfds]

Great work I love the MYST-like look.
As a fellow Povray user I have to ask: The light beam is emitting media? And where did you get the trees?

[Crayons]

Great work I love the MYST-like look.
As a fellow Povray user I have to ask: The light beam is emitting media? And where did you get the trees?

Ah!
Right (apologies to non-POV users here!)
The light beam is a media cylinder and a cylindrical light source.

cylinder { < 0, 0, -300>, <0, 0, 20>, 3  
    pigment { rgbt 1 } 
    hollow
    interior { media { scattering { 1, 0.001 extinction 0.01 } samples 30,100 }  }
}
light_source { <0, 0, 20> color rgb <150, 150, 350>
    cylinder
    radius 2
    falloff 4
    tightness 5
    point_at <0, 0, -300>
}

[Hrm, the editor seems to remove indents!]
To be honest I haven't got a complete "handle" on all the parameters used so I tend to use "educated trial and error" for what I want and as usual, Serendipity often has the final word! As you can see the light is pretty bright ! The "sun" I'm using is only rgb 2*<1, 0.97, 0.94>.
I'm all up for any advice on these matters, this is only my second attempt using media.

The trees? Home made. With the exception of the "leaves" on one tree - which uses a highly modifed leaf texture tile from Maptool/FM8 - everything in this entire design is essentially home made. Whilst I'm sure you're aware there are one or more tree generator POV sources available for free on the web, they're all "too good" i.e represent the workings of real POV experts seeking perfection. Whilst I admire their works, I needed some simple, rather quicker to render, trees. So a fairly simple four layer random branching algorithm and some simple leaves...

[The trees on roofs and paths are in pots!]
The "tree fern" thing is just some tori for the trunk and a sliced up sphere/cone difference for the "leaf", the "normal tree" has each branch ending with a sphere image_mapped with that leaf texture I mentioned - modified so that the darker shades were transparent - and the "cactus" is just 6 flattened spheres rotated to make a segment with a load of spines that are frankly a little OTT for detail here. I tend to try and create stuff I can add to my "library" of bits for other projects later on.
Any help? ( I'm happy to give people source for this stuff - just give me time to tidy up the messy code and add the appropriate CC license! )

[RobA]

[Hrm, the editor seems to remove indents!]

use the CODE bbtag to wrap it. (I changed it for you)

-Rob A>

[Crayons]

Cool! Thanks!

[cfds]

Ok, that's how you did it, I only hope you have disabled media interaction for your "sun" light source.. And the trees are great, even close up.

[Crayons]

Ok, that's how you did it, I only hope you have disabled media interaction for your "sun" light source.

Actually, I haven't. I figured that if the light beam is lighting up particulate matter thus then so would the sun. You might have noticed in the render with the reflectors and the multiple beams that there is a general area of interaction around the scene caused by my using a single large cylinder as the media "container". I'm gonna try this again with separate smaller cylinders for the media - constraining the media to the beam sizes. However, this might just take longer to render... or even bug out with a memory problem! Gah.
I'm not experienced with media. Is it likely to speed up my renders if I disable media for the sun and use the larger single media container?

Erm, on the other hand - media is not an area I'm particularly concentrating on right now, mind! It's needed here obviously but... I'm just a hobby renderer.
The kind of POVray work I'm experimenting with here within the auspices of CG are related to simplifying and speeding up POVray for mapping purposes.

[Crayons]

OK, still on the case. I've been rendering stuff and working on the underground as well (TBA). Anyway, this is a section of stitched together map view in the raw. I intend to do a bit of this and that on it with PSP X too - but not a lot. I'm currently targeting the final result at an A3, 300ppi thing...(I think!)

Query: That size of image is gonna be pretty large. Does that represent any problem? Is there a preferred file format or jpg compression factor advised here? The attached is a jpg compressed with a "factor" of 30, for example.

### LATEST WIP ###

[Gamerprinter]

There's a limitation about 4000 pixels wide and 4.25 MB so consider that and maybe created a 50% compressed JPG for final output. The system won't successfully load a file that's too big, so you'll know right away if the file you create is too big.

GP