In article <bCW1OIjrykoVBR6nY5iI6VMKZ3UL@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> : df3 output, dfc file
...
> My idea is that a new file type triggered by a comman-line (or INI)
> option is introduced. An additional depth parameter to output
> resolution has to be introduced, too. The program would then sample
> the unit cube at width*height*depth points and save the clipped
> brightness directly to a density file. Brightness should only be
> affected by pigments and media density.

Maybe something could be added to my object pattern...my proximity 
pattern might also benefit from this(compute the density pattern once 
using high settings for proximity, then use the density pattern instead 
of the proximity).


> A new type of density file (for example dfc), one that stores
> three-dimentional RGB data, would also be of use. The RGB data could
> then be used as a default color map for the density_file pattern based
> on this file if no color map is specified. Combined with df3 or dfc
> output one could easily render a glowing media version of any object,
> while preserving the colors.

Where would you get the color data from a CSG with multiple textures? 
Just add the color contribution from every object? And you would have to 
restrict yourself to the pigment, since the other features(normal, 
finish) kind of depend on having a surface.


> : strict variable types
...
> : promotion
...

I have often wished for this. I think the basic types would be:
char
int
float(maybe replace int and float with "scalar"?)
material, media, color_map, texture, etc.
object(all shapes would be of this type)
pattern(I really think patterns should be variable types too)
function(an isosurface function, it might be a good idea to let these be 
used in normal code too)

A clearer declaration syntax would be nice too:
#declare VarName = (Type) VariableStuff;
The closing semicolon would be used for all data types, instead of just 
for vectors and scalars.
Also, #declare and #local would only be used to create variables. You 
could then modify them without these keywords:
#declare MyCounter = (int)0;
MyCounter = MyCounter + 1;


> : hash variables
> 
> A hash variable is like an array but in addition to an index, each
> element has a name by which it can be invoked. For example,
> Posters[155] doesn't tell much while Posters[Peter_Popov] does, and
> they mean the same to the parser. One useful feature is that they make
> passing parameters to a macro much easier.

I think list structures(and maybe tree structures) would also be good 
additions. Or at least the ability to add to and insert into an existing 
array.(a separate data structure would likely be easier to code and 
would have a cleaner syntax)


> : spotlight scale
> 
> Non-uniform scaling of spotlights would allow for elliptical
> spotlights.

And don't forget cylinderical lights.


> : polygonal spotlight
> 
> Although unrealistic, these have their applications. Combined with an
> area light, they can be used to simulate, for example, light passing
> through a window or keyhole or similar.

This is an interesting idea, but couldn't it be done with the 
projected_through patch?


> : chop pieces off with bounding
> 
> If a bounding object is smaller than what it bounds, the results are
> unpredictable. I think a more logical behaviour would be the one seen
> in isosurfaces, i.e. the bounding object should restrict the bounded
> object, exposing the intersection surface and texture. Of course, it
> would still bound the object for ray-shape intersection tests.

This might be a good idea. On the other hand, it would reinforce the bad 
habit of using bounded_by as a kind of CSG...(remember that with some 
settings POV can override this statement and use it's own bounding)


> : leave original textures when CSGing
> 
> When performing a CGS difference or intersection, any object with a
> non-specified texture is assumed to have a black pigment and ambient
> 0. I think a more reasonable behaviour would be to ignore its texture
> and use the texture of whatever object the intersection point is in.
> Of course this could lead to "coincident interiors" problems but I
> think with proper CGSing they can be avoided.

Actually, I am pretty sure it uses the default texture, which you can 
set with the #default keyword. And I think it would be extremely 
difficult to determine which object to choose the texture from...what if 
the point is enclosed in more than one object? The current behavior of 
using higher level textures or per-object textures if defined or the 
default texture otherwise seems to make more sense.


> : seeded randomness for area_light and aa jitter
> 
> This one is pretty straight-forward. It would make animation people's
> lives easier.

I don't think this is possible. Providing a seed would allow you to 
specify the sequence of random numbers used, but you still can't decide 
when they are used. If a point gets covered up doesn't need a random 
number computed or if something causes a pixel to need more numbers than 
it did before, everything get unsynchronized and you end up with the 
same "flying pixels" or static.


> : Additional BRDF models
> 
> I recently used a rendered which supported 11 differend BRDF
> (highlights) models. Now that's cool! The authors were kind enough to
> share some of their sources with me:
> 
> http://www-graphics.stanford.edu/~smr/cs348c/surveypaper.html
> http://www.cs.columbia.edu/CAVE/curet/
> http://www.ciks.nist.gov/appmain.htm
> 
> Some of them have properties very useful for specific tasks, such as
> anisotropy (for a brushed metal look).

I will have to look at those sites...

Other features I can think of:
Simple shaders: really just an extended isosurface function capable of 
handling vectors and colors. Not necessarily as full-featured as "real" 
shaders, but potentially quite useful.

Patterned light_source's: Have the ability to apply a patterned 
color_map to a light source, with the option to use ray direction and 
depth instead of point position.(which would kind of simulate light 
coming through a colored, transparent sphere surrounding the light 
source, but with depth)
light_source {blah, blah
   PATTERN
   color_map {...}
   use_depth_for_z on/off
}

If the "use_depth_for_z"(somebody please come up with a better keyword!) 
feature is turned on, the angles of the initial emission from the light 
source will be used for the x and y axis, and the distance the ray has 
travelled for the z axis. This should make things like interference 
patterns possible.(I wonder what this would look like combined with 
scattering media and photons!)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message