Newsgroups: comp.graphics
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!news.UVic.CA!csr!bcorrie
From: bcorrie@csr (Brian  Corrie)
Subject: Re: Scene description: RayMond, comp.gfx's own scene description...:-)
Message-ID: <bcorrie.674237176@csr>
Keywords: Ray Scene
Sender: news@sol.UVic.CA
Nntp-Posting-Host: csr.uvic.ca
Organization: University of Victoria
References: <625@lysator.liu.se> <bcorrie.673902754@csr> <629@lysator.liu.se>
Distribution: comp
Date: 14 May 91 16:06:16 GMT

zap@lysator.liu.se (Zap Andersson) writes:

>[Lot 'o blah blah of min deleted]
[Lots of mine deleted too]

    [You say]

>>>* Effichiency shemes thrown in

    [I say]

>>This is part of the renderer. Some help in the interface may be a bonus, but
>>I don't know that it should be part of the standard. In a sense, the graphics
>>state can be used to realize a hierarchical structure in the objects. Since
>>things within a transformation block are likely related (since they are
>>transformed together) this can be used to get a tree structure on the objects
>>for those techniques that use such an algorithm. As a fundamental question,
>>I don't think that the modeler/renderer interface should specify how things
>>are grouped. It should be a job of the renderer to determine this hierarchy
>>based on the efficiency scheme that it uses. If it can't determine a good
>>hierarchy for an arbitrary scene, then it is probably not a terribly good
>>efficiency scheme (Now that I've said that, lets temper the remark with the
>>fact that this is an open research question in ray tracing. I don't think
>>any efficeincy scheme works best on all scene descriptions. The good ones
>>do well most of the time though 8-)

    [Oh Oh, I'm in trouble 8-)]

>AHA! NOW you ar on deeeep watrs my friend, a topic near and dear to
>my heart :-) hh heh heh :-) 
>Like you said: No scheme is best for all images. Oftn, th bst way is to
>allow th modllr (i.e. the luser) to say: OK, this thing I want a grid
>around, do octr around these, and do bounding boxes hre, and zap-locked
>thermal tracing on those balls in the corner...

I agree that it is often necessary to do this, but the number of different
ways that renderers can provide efficiency techniques seems like too
complex of a requirement to put on a modeller/renderer interface. RenderMan
does provide hierarchy to a degree (Ri*Begin/Ri*End blocks) as well as bounding
boxes, two of the most common efficiency schemes. Unfortuantely, different
rendering schemes use very different techniques to acclerate things (Scan
line techniques VS Ray Tracing for example). I think maybe the best way to
deal with this is to extend the RIB interface to suit your renderer a bit.
I don't know for sure, its certainly a tough problem, but RenderMan was designed
to be renderer independent, so it seems to me that this task should go somewhere
else in the pipeline.

Of course we could debate all day about this one 8-) At least we agreed on most
of the points....

See ya later,
		B
--
                  Brian Corrie (bcorrie@csr.uvic.ca)
Under the most rigorously controlled conditions of pressure, temperature,
volume, humidity and other variables, the organism will do as it damn well
pleases. Sounds like some of the code I have written......  8-)
