Logo

[Rázsó István]

Hi,

A few days ago I wrote a letter, but I have sent it to Pete. 
Now I resend to the list. Here it comes:

Hi,

Personally I don't like the idea to render letters from different shapes. It
is used too often. I prefer more original ideas. I have some ideas, how we
can use the triangle. Maybe these are not the 'more original' ones :>

Idea 1:
 It can be a warning triangle (used in cars), with an exclamation mark in
the middle. 'Panorama' as simple text at the bottom.

Idea 2:
 Traffic sign: 'give way' (or 'priority sign' ). Panorama written
somewhere...

Idea 3:
 Traffic sign: 'danger' sign

Idea 4:
 The triangle can be an earring, the text 'Panorama' engraved on one side.
We can have a bigger rendering of womans' face from one side (not straight),
with eyes, nose, ear and earring. The logo can be the part of it, or a
standalone rendering of the earring (or pair of earring).

I'll have a new job from october. I hope I'll have time to refresh my C++
knowledge and start developing for panorama (not just reading the mailing
list, and writing ideas without trying them :).

Steve
>From address@hidden Wed Sep 27 13:29:06 2000
Received: from arachne.eng.utah.edu ([155.99.222.1])
        by fencepost.gnu.org with esmtp (Exim 3.16 #1 (Debian))
        id 13eL0z-0002Af-00
        for <address@hidden>; Wed, 27 Sep 2000 13:29:05 -0400
Received: from lab4-11.eng.utah.edu (lab4-11.eng.utah.edu [155.99.222.160])
        by arachne.eng.utah.edu (8.9.1a/8.9.1) with ESMTP id LAA15666
        for <address@hidden>; Wed, 27 Sep 2000 11:29:02 -0600 (MDT)
Received: from localhost (address@hidden)
        by lab4-11.eng.utah.edu (8.10.0.Beta12/8.10.0.Beta12) with ESMTP id 
e8RHT2v20414
        for <address@hidden>; Wed, 27 Sep 2000 11:29:02 -0600
Date: Wed, 27 Sep 2000 11:29:02 -0600 (MDT)
From: Kevin Harris <address@hidden>
To: Panorama Developer List <address@hidden>
Subject: Experimental additions I want feedback for...
Message-ID: <address@hidden>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/devel-panorama>, 
<mailto:address@hidden>
List-Id: Developers list for Panorama, the GNU framework for 3D graphics 
<devel-panorama.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/devel-panorama>, 
<mailto:address@hidden>
List-Archive: http://mail.gnu.org/pipermail/devel-panorama/

I've made quite a few changes to panorama, and I would like some input
before (if at all) I check them in.  I'm not sure that everyone will
appreciate what I've changed, or the slowdown incurred by the changes.

I've added area lights by means of an 'emission' pattern for every
material.  This required that every object be given a function to return a
random point on the surface (easier than a 2d-3d mapping), with a default
provided at the 'center' of the object.  One problem arising from 
adding the area light sources is that a HUGE number of samples must be
taken for each pixel to get a decent image. 

Lights need not be included explicitly in the scene section of the rt
format.  They can be detected automatically and added.  As a bennefit
here, I've allowed pure light sources (point lights, etc. are all
subclasses of 'TObject') to be included in aggregates, csg (intersection
or difference doesn't make too much sense), or whatever.  This allows
objects to be defined with light sources in them, and they can be multiply
instantiated, transformed, translated, etc, and have the light stay with
the object.  This does not currently work for all pure lights or with halo
(I don't know why yet).  These bugs only apply to lights that have been
transformed 'externally', by inclusion in another object (such as an
aggregate, or union) that is being transformed.  

A side effect of this involved a slowdown whenever sending a ray to a
light -- a matrix multiply is used to transform the lights position, and
to transform the relative world coordinates into it's local system (for
falloff, etc.).  This is the part that I would assume most people would
dislike, as it could slow down the rendering by a HUGE amount.

So... The slowdowns involved by these changes are a few extra matrix
multiplies for pure light sources, and a requirement of a large number of
samples for area lights.

I would like to hear if anyone actually would like these changes I've been
making.  If I get a positive response, I'll merge my stuff (not completely
bug free yet -- I will probably need help with that) back into the tree.

A couple of example images of area lights can be found at:
http://www.eng.utah.edu/~kpharris/panorama/panorama.html

Patiently awaiting comments,
-Kevin-