[Bf-committers] Camera, displacement and normals
Wed, 21 Jan 2004 12:14:51 +0100
Builtin panorama render works fine for your file:
http://www.blender.org/bf/pano1.jpg (your file, "Pano", 2 parts)
bump and a "Sun" lamp don't work well, here's a lamp:
and the real power is setting the slices small, and render more parts:
If you want 360 degree panoramas of environments look good, you have to =20=
allow such nice curved lines, works excellent for panning. In NeoGeo =20
days, we used it for the LostRide game, which had wide panorama views =20=
of a 'ride', and allowed the viewer to look around about 180 degrees.
I didn't check why individual renderings don't work... maybe 90 degree =20=
slices with a Sun and an extreme wide-angle lens can cause some errors? =20=
Don't have time now to dive into this, with the official method (Pano) =20=
On Wednesday, Jan 21, 2004, at 09:31 Europe/Amsterdam, Gregor M=FCckl =20=
> Am Wednesday 21 January 2004 03:15 schrieb Robert Wenzlaff:
>> On Tuesday 20 January 2004 09:38, Gregor M=FCckl wrote:
>>> I'm currently in the process of building a game engine which allows =20=
>>> player to look at panoramas, with viewing angles of 180 degrees in =20=
>>> vertical direction and 360 degrees in the horizontal direction.
>>> I am able to render these panoramas within blender with a small =20
>>> trick: I
>>> use a camera fov of 90 degrees and render 6 images - two along each
>>> coordinate axis - and project them onto a cube which is rendered in
>>> realtime. This method works quite good.
>>> Obviously, the rendered images must fit together seamlessly to =
>>> this illusion. However, I discovered, that when mapping texture =20
>>> onto the displacement or normal of a material, the images won't fit =20=
>>> expected. This is quite disappointing because of this these features
>>> aren't available to the artists working on this game.
>>> Why is this? Does blender's renderer use the camera front vector =20
>>> of the ray direction for this? With a field of view of 90 degrees =
>>> angle between these gets to 45 degrees at the edge centers and even
>>> greater than this at the corners of the image. This would explain =
>>> effects I'm seeing.
>>> Is there a reason for doing it the way it is done right now? Would =20=
>>> it be
>>> a big deal to alter this behaviour?
>> It may have been related to the normal flipping, or I may not quite
>> understand the steps to recreate this. But after the last commit, I =20=
>> these two images with the camera at the origin, and rotated 90 =
>> between #1 and #2.
>> Pasting them together, I see no seam
>> Robert Wenzlaff
> Thanks for your effort. This is indeed quite strange then. I do see =20=
> seams when
> I render in blender. I've created an example of what I try to do in =20=
> (using yafray as renderer turns out to work, btw).
> The scene is
> The created images are:
> If I put the images together I clearly see a seam:
> The two camera positions which I used for this test are stored as keys =
> frame 1 and 2.
> Bf-committers mailing list
Ton Roosendaal Blender Foundation firstname.lastname@example.org =20