Re: G3DKit.info - renderer questions

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