Re: Lights I/O

[Stefan H. <st...@to...>]

I've written two simple binary files with my app: one using QD3D and 
the other using Quesa (using your patch). Then I compared the 
viewhints (byte for byte).

In my case QD3D has written

Container
   ViewHints
   Container (view angle aspect camera...)
   Container (renderer...)
   Container (ambient light...)
   Container (direct light...)
   Container (attribute set...)
   ImageClearColor
   ImageDimensions

and Quesa:

Container
   ViewHints
   Container (view angle aspect camera...)
   Container (ambient light...)
   Container (direct light...)


Quesa currently seems to ignore certain parts. But the other parts 
are absolutely binary compatible with the QD3D output. The size of 
the main container has been correctly calculated.

But QD3D has not accepted the file. Then I copied the viewhints of 
the QD3D file into the Quesa file (Quesa geometry with QD3D 
viewhints): QD3D can read this.

It doesn't seem to be a container problem. Maybe QD3D wants the whole stuff...

Stefan



>I have modified my version of Quesa as Stephan requested but it 
>seems no better.
>If you would like to try it, in E3FFW_3DMFBin_Writer.c, line 542 reads:
>
>					qd3dStatus = 
>Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
>
>If you change this (yes I know its a horrible way to do it) to:
>
>					{
>					if ( 
>instanceData->stack[i].objectType == kQ3LightData )
>						qd3dStatus = 
>Q3Uns32_Write ( kQ3ShapeTypeLight, theFile ) ; // To allow light 
>data objects to be read by QD3D
>					else
>						qd3dStatus = 
>Q3Uns32_Write(instanceData->stack[i].objectType,theFile);
>					}
>
>  Then this produces the requested data in the output file.
>
>I think the other problem may be that the light is in a 'container' 
>which QD3D does
>not expect, but I have no idea how to get rid of the container, it 
>seems everything
>in Quesa has to be in a container whether you want it or not.