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

[Brent Gulanowski]

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?

--
Brent Gulanowski                                address@hidden

http://inkubator.idevgames.com/
Working together to make great software.