Re: Lights I/O

[Roger H. <rog...@mi...>]

On 3 Jul, 2005, at 17:34, Stefan Huber wrote:

> I've found several aspects to improve viewhints i/o in Quesa.
>
>> Going through the different parts in turn:
>>
>> The renderer is missing because whoever wrote the interactive
>> renderer forgot to write the code which writes it out, however,
>> this does not seem to be much of a problem, as any other
>> QD3D renderer does have this code. For instance
>> if the Microspot renderer was selected at save time, the
>> renderer does get written. If there is no renderer we default
>> to the interactive renderer and all is well. I guess this might
>> be a problem for you but I doubt it.

Strange to comment on my own comments, but I have tried out my old OS8 
code
and the first thing it gets out of the View Hints is the Renderer. If 
there isn't one
it throws an exception and does not read the rest of the view hints.

>
> In Quesa it's not really a problem for me, but it might be a problem 
> with backward compability (see below). But IR_TextureFilterMode would 
> be quite useful (in QD3D writing texture filter mode seems not to 
> work).
>
>> I am surprised about the container around the individual lights,
>> the documentation for the 3D Meta File format shows them as
>> loose items.
>
> The documentation is not perfect; some information is not compatible 
> with 3DMF version 1.5/1.6. I think we should use the v1.6 output as a 
> reference.

OK

>
>> The code for writing out the attribute set, the clear colour and the
>> image dimensions is there, though it does not get called unless
>> you add these items to the view hints object. Maybe I am missing
>> something here.
>
> QD3D always writes the whole ViewHints data. In
>   e3viewhints_new (file E3IOData.c)
> this behaviour is partly implemented (if paramData...): Camera and 
> lights are ok, renderer is basically ok (as you mentioned above: 
> depends on the renderer type), default attributes should use 
> Q3View_GetDefaultAttributeSet (not Q3View_GetAttributeSetState, I 
> suppose), and clear color/dimension should be initialized from the 
> draw context data.

Why should we use Q3View_GetDefaultAttributeSet instead of 
Q3View_GetAttributeSetState ?

>
>> I do not need backward compatibility but I would like to sort this out
>> for you if you do need it. Any chance of patching the file to find
>> out which particular aspect is tripping up QD3D?
>
> Currently I have not found a particular aspect; ignoring the viewhints 
> as well as reading the complete viewhints seems to work. Certainly, 
> I'm missing something, but what?
>
> My suggestions are:
> - upload the "kQ3LightData as 'lhgt'" hack
> - change e3viewhints_new (the "if paramData" section)


> - Quesa renderers: write the renderer settings out

This is a job for the someone familiar with the interactive renderer 
code. Its not part of View Hints, I am asking the Renderer to write 
itself out.

The best I can do for this (and it works for my OS8 app code) is when 
creating an empty View Hints, I set the renderer to the interactive one 
by
default. As this code almost certainly only get called by the View Hint 
reading code, then if there isn't a renderer in the view hints then the
default interactive renderer will not get overwritten.


Roger