Re: Q3TriMesh_GetData

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

On 16 Sep, 2008, at 19:43, James Walker wrote:

> Roger Holmes wrote:
>> On 16 Sep, 2008, at 18:23, James Walker wrote:
>>
>>> What about doing the sanity check in e3geom_trimesh_new, so it would
>>> cover TriMeshes created by means other than reading 3DMF?
>>
>> Yes that would be better. Am I right in thinking there is no way for
>> an application to change a TriMesh after e3geom_trimesh_new creates
>> it, other than recreating it totally. I know the main attribute set
>> might be shared with other things but that is all that can get  
>> changed
>> "when you're not looking" I think.
>
> It is also possible for the application to change the TriMesh using
> Q3TriMesh_SetData or Q3TriMesh_LockData.

OK
>
>
> The function e3geom_trimesh_optimize is called in 3 places:
> e3geom_trimesh_new, E3TriMesh_SetData, and E3TriMesh_UnlockData (in  
> the
> read-write case), so that might be a reasonable place to fix bogus
> edges.  Or else have a separate validation function that is called  
> just
> before e3geom_trimesh_optimize in each place.

Yes that sounds better, we might want to call either routine  
separately one day and it keeps the names more meaningful.
>
>
> While we're at it, it might make sense to sanity-check the point  
> indices
> of faces and edges, but in those cases there is not a reasonable way  
> to
> fix a problem, so the validation function should probably be able to
> cause a kQ3Failure result.
>

I suggest we return kQ3Failure and also set the faulty indexes to  
zero. I know that will give strange looking data, but I think that is  
better than crashing. Anyway, an application should see the kQ3Failure  
and deal with it some other way, it is only apps which plough on  
regardless which will actually display the faulty data.

In a way it is a shame there is not a third alternative to kQ3Failure  
and kQ3Success, something like a warning which we could return in the  
case of an edge which we have made safe.

Roger Holmes.