[Bf-committers] Camera, displacement and normals

[Ton Roosendaal]

Hi,

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:

http://www.blender.org/bf/pano2.jpg

and the real power is setting the slices small, and render more parts:

http://www.blender.org/bf/pano3.jpg

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=

working nicely.

-Ton-



On Wednesday, Jan 21, 2004, at 09:31 Europe/Amsterdam, Gregor M=FCckl =20=

wrote:

> Am Wednesday 21 January 2004 03:15 schrieb Robert Wenzlaff:
>> On Tuesday 20 January 2004 09:38, Gregor M=FCckl wrote:
>>> Hi!
>>>
>>> I'm currently in the process of building a game engine which allows =20=

>>> the
>>> player to look at panoramas, with viewing angles of 180 degrees in =20=

>>> the
>>> 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 =
create
>>> this illusion. However, I discovered, that when mapping texture =20
>>> output
>>> onto the displacement or normal of a material, the images won't fit =20=

>>> as
>>> 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
>>> instead
>>> of the ray direction for this? With a field of view of 90 degrees =
the
>>> 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 =
the
>>> 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=

>> ran
>> these two images with the camera at the origin, and rotated 90 =
degrees
>> between #1 and #2.
>>
>> http://www.soylent-green.com/Test1.jpg
>> http://www.soylent-green.com/Test2.jpg
>>
>> Pasting them together, I see no seam
>>
>> http://www.soylent-green.com/Test1-2.jpg
>>
>> 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=

> blender
> (using yafray as renderer turns out to work, btw).
>
> The scene is
>
> http://quark.futureware.at/panotest.blend
>
> The created images are:
>
> http://quark.futureware.at/test0001.jpg
> http://quark.futureware.at/test0002.jpg
>
> If I put the images together I clearly see a seam:
>
> http://quark.futureware.at/test-complete.jpg
>
> The two camera positions which I used for this test are stored as keys =
=20
> in
> frame 1 and 2.
>
> Regards,
> Gregor
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------=20=

--
Ton Roosendaal  Blender Foundation ton@blender.org =20
http://www.blender.org