On Sat, 26 Feb 2000 13:22:22 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Therefore, I would probably just add integer types (maybe char, but most
>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

These should suffice, really. And at first I didn't realize the
problems a person with no programming background might run into when
working with unsigned types. You're right, leave'em out.

>> : promotion
>
>Promotion is currently automatically done when needed.  I like that approach
>better.  Sure, automatic type casting can lead to unexpected results if the
>coder doesn't pay attention to what they're doing, but if there the number
>of variable types is kept to a minimum, and a logical promotion sequence is
>used, then this can greatly ease the task of the coder.

I will have to trust you on this one because you're the programmer,
not me :)

>Maybe what you're looking for is this:
>#declare ABC=Posters["Peter_Povpov"];

Yes, of course you're right, a string used as an index is what I had
in mind.

>> : polygonal spotlight
>
>My first thought is to use projected_through.  Do that with an area light
>and you get realistic falloff, although I realize that doing such would not
>be as fast as what you are proposing.

I think Stephan Ahonen was working on such an extension for Blender
(I'll have to check my ICQ message archive). I'll see if I can get him
(or whoever it was who worked on that project) share some source.

>Use CSG.

I'm just giving this idea up because it is not a really good one.

>> : leave original textures when CSGing
>
>Probably won't work as well as you'd expect.  But I don't want to dismiss it
>without looking closely.  It is potentially a very useful idea and may not
>be as difficult to implement as I am imagining.  I would definately say that
>it should be a special option for backwards compatibility reasons.

My heart is filled with hope :)

>> : seeded randomness for area_light and aa jitter
>
>As mentioned by Chris, this may not be possible.

Use the pixel coordinates as a seed and there you go!

>> : zero text object thickness
>
>Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
>pattern would be better.  This way you could apply the TTF object to another
>infinitely thin object (such as a disc) and use filter/transmit to get the
>clear part.

Also, support for '\n' and '\t' in text objects (and for '\t' in
strings) would be useful. Stuff like justification would probably be
overkill (and can be done with a macro anyway).

>> : on error do something useful (skip frame etc.)
>>
>> OK this one I admit is a bad habit I have from my BASIC years :)
>
>Actually, your example looks quite a bit like an exception-handling block,
>and I see a lot of potential usefullness in it.

Really? But that would involve return codes for most operations etc.
Also, what would happen if this block in included, or even worse,
overlaps, a #while..#end, #if..#end or even a #macro..#end block?

>> : Additional BRDF models
>
>I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
>models.

Ditto to that.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message