Re: Lights I/O

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

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.

I am surprised about the container around the individual lights,
the documentation for the 3D Meta File format shows them as
loose items.

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.

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?

Best regards,

Roger.




On 24 Jun, 2005, at 01:14, Stefan Huber wrote:

> 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.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>