Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!news.funet.fi!cc.tut.fi!jk87377
From: jk87377@cc.tut.fi (Juhana Kouhia)
Newsgroups: comp.graphics
Subject: Re: Scene Description Standard
Message-ID: <1991Apr30.151157.6786@cc.tut.fi>
Date: 30 Apr 91 15:11:57 GMT
References: <1991Apr30.003612.16050@mks.com> <30137@rouge.usl.edu>
Organization: Tampere University of Technology
Lines: 38


In article <30137@rouge.usl.edu> msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes:
>
>However one should also have some kind of procedural features.
>
>	for(x = 0; x < 100; x++)
>	    for(y = 0; y < 100; y++)
>		FirTree(x + dither(), y + dither());

Now the main algorithm for the ray tracers in the net is

   1. build the scene
   2. trace it

I have designed my program so that I can generate the objects on the fly
with the modelling language I have in the program.
For example, if I have a crass field I can present it by program code,
it takes a bit memory and is nearly as fast as if I store each crass
to the memory; a large one memory.
In the article John M. Snyder and Alan H. Barr, Ray Tracing Complex
Models Containing Surface Tessellations, SIGGRAPH '87 Proceedings they
made a large field by copying a small crass field part to the
several places; of course you don't see the similarities easily, but
if our field is not equally distributed it causes problems with the
memory.

>but it may be more important to parameterize by, say, the surface
>color, texture etc.

If you mean "sphere r g b texture pos_x pos_y pos_z"-type
presentation I say no.
It's much easier if every parameter is possible to replace by a
small program - user can make that program too.
RenderMan is good example.

That all guess means that the program must be in object format not
executable.

Juhana Kouhia