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: Keywords: Ray Scene Sender: news@sol.UVic.CA Nntp-Posting-Host: csr.uvic.ca Organization: University of Victoria References: <625@lysator.liu.se> <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-)