Re: [Gnu3dkit-discuss] G3DKit.info - renderer questions

[Philippe C . D . Robert]

On Thursday, October 31, 2002, at 08:39  Uhr, Brent Gulanowski wrote:
> On Thursday, October 31, 2002, at 07:01  AM, Philippe C.D. Robert 
> wrote:
> > On Thursday, October 31, 2002, at 04:10  Uhr, Brent Gulanowski wrote:
> > > On Wednesday, October 30, 2002, at 05:23  PM, Philippe C.D. Robert 
> > > wrote:
> > >
> > > > My terminology here is:
> > > >
> > > > o [action] a highlevel "job" to be performed on the scene graph, 
> > > > ie. culling data for the active frustum. This is thus generic.
> > > >
> > > > o [task] a specific low-level "job" performed by the render engine, 
> > > > ie. switching a state (simple) or drawing arbitrary geometry 
> > > > (complex). This is thus specific.
> > > >
> > > > Do you think this is a bad choice? I can see both possibilities, as 
> > > > long as it is used consistently...:-)
> > >
> > > I'm pretty sure that, wherever you slice it, the word "action" means 
> > > some particular activity, usually a well-defined activity or 
> > > process. An action has no ambiguity. It also has little or no 
> > > implicit impact on a state. It may have no consequences at all. A 
> > > task is different in both ways -- it usually does not define the 
> > > particular process followed to complete the task (which may be 
> > > actions, or may be sub-tasks which are themselves composed of 
> > > specific actions), and it does imply a meaningful change of state. 
> > > There's a grey area between them, but in this case, I recommend 
> > > swapping the terms.
> >
> > Well, if you ie. have a look at Inventor then you see that there a 
> > SoAction is described as follows:
> >
> > "SoAction is the abstract base class for all actions. Classes derived 
> > from SoAction define operations to be applied at each node 
> > encountered during traversal of a scene graph. The function that gets 
> > called to implement the action for a particular node type is 
> > determined by a lookup table in the global database."
> >
> > The SoGLRenderAction class for example traverses a scene graph and 
> > renders it using the OpenGL graphics library. Thus I'd rather keep 
> > the terminology, otherwise it gets confusing...
>
> OK, but they don't use the term "task" at all.  My only reason for 
> commenting at all was that the usage here somewhat contradicts the 
> normal English usage -- a pet peeve of mine in science and technology 
> terminology. Try to get some programmer to explain the difference 
> between an "argument" and a "parameter". :-)
>
> The Open Inventor usage (which, btw, is never justified that I can 
> find -- I guess I'd have to buy a tutorial book) -- suggests 
> functionality like your "task" -- but -everything- is -called- an 
> action. The superclass is a generalization of a type, not an 
> aggregation. In other words, all SoActions have the same level of 
> granularity. A task, on the other hand, can be thought of as an 
> aggregation of actions -- at least, that was the point of my last 
> email. So if you define a class which groups a number of actions, you 
> could call it a task (if there was any point to such a class).
>
> Similarly, I would consider most controller classes, in fact, as 
> representing a task (or "job"), and each method in the class as an 
> action performed as part of its (implicit) task. Rendering is a task, 
> performed by a renderer. Drawing is a sub-task. Submitting vertices to 
> the pipeline is an action. But I'm not advocating putting the term 
> "task" in the name of any classes. It would be easier, probably, to 
> not use the term "task" at all in any but descriptive usage. In which 
> case, I don't think you'd have to worry about contradicting Open 
> Inventor standards/terminology.
> Which raises a question -- what are Open Inventor standards, and what 
> is the justification for using them?

It is not just Inventor, it is a common term in many different scene 
graph APIs. And in general I think it is a GoodThing to use the same 
naming whenever it is appropriate. This will help others to get 
familiar with the kit.

But I am happy to change the term 'task' to whatever else fits better. 
Suggestions are welcome!

-Phil

PS: You do not have to buy a book, just use Google ...:-)
--
Philippe C.D. Robert
http://www.nice.ch/~phip