Re: [Celestia-developers] CMODTool

[Da W. J. <dir...@gm...>]

Now I remember the specifics of this bug - what happened was that a
3ds model converted with the 3dstocmod (included with Celestia) ended
up having "nan" (not a number) written into some of the texcoords.
Instead of completely discarding the model as you're suggesting,
replacing the nan texcoords with "0.0" seemed to result in reasonable
rendering, but admittedly it's still a hack.

Cheers,
DW

On 11/20/06, Chris Laurel wrote:
> It appears that there is a bug, but I don't see how it would affect
> models without texture coordinates. It looks like the vertex data is
> being deleted if a non-numeric value appears in the vertex data.
> Instead of continuing to try and read more data into the unallocated
> vertex data buffer, the function return NULL immediately aftering
> freeing vertexData.
>
> --Chris
>
> On 11/19/06, Da Woon Jung wrote:
> > This crashing problem has not been addressed yet.
> > On first glance, it only appears to be an issue with cmodfix, but
> > actually the bug is in modelfile.cpp, and so could it be triggered by
> > loading a model lacking some texture coords into Celestia?
> >
> > Here is a patch:
> >
> > Index: modelfile.cpp
> > ===================================================================
> > RCS file: /cvsroot/celestia/celestia/src/celengine/modelfile.cpp,v
> > retrieving revision 1.15
> > diff -d -p --unified=3 -w -r1.15 modelfile.cpp
> > --- modelfile.cpp       13 Sep 2006 05:58:47 -0000      1.15
> > +++ modelfile.cpp       19 Nov 2006 15:28:27 -0000
> > @@ -550,10 +550,12 @@ AsciiModelLoader::loadVertices(const Mes
> >                  if (tok.nextToken() != Tokenizer::TokenNumber)
> >                  {
> >                      reportError("Error in vertex data");
> > -                    delete[] vertexData;
> > +                    data[j] = 0.0;
> >                  }
> > +                else
> > +                {
> >                  data[j] = tok.getNumberValue();
> > -
> > +                }
> >                  // TODO: range check unsigned byte values
> >              }
> >
> >
> > On 10/5/06, Chris Laurel wrote:
> > > I can't think of any reason why cmodfix --tangents should fail just
> > > because some (or even all) submeshes don't have texture coordinates.
> > > 'Tangents can't actually be determined for those submeshes without
> > > textures coordinates, but the program shouldn't fail conversion
> > > completely. I'll have a look at fixing it in the next couple days. I'm
> > > in The Netherlands at the moment and temporarily separated from my
> > > laptop, otherwise I'd take care of this sooner.
> > >
> > > --Chris
> > >
> > > On 10/5/06, Da Woon Jung wrote:
> > > > On 10/5/06, Martin Charest wrote:
> > > > > Here's another model which don't pass the test.  I'm giving you a link to a
> > > > > 1.8 MB zip file which contains the 3ds version, and its TEXT CMOD version
> > > > > (without any option checked).  I can't convert it with Generate Tangents
> > > > > selected.  There are many other models which don't pass the test.
> > > > >
> > > > > (url removed)
> > > >
> > > > (I'm cc'ing Chris)
> > > >
> > > > Martin,
> > > >
> > > > In this case, thankfully the answer is simple. J2Test consists of
> > > > meshes that don't all have texture coordinates. Some parts of the
> > > > model do have texcoords, some don't. The trouble is cmodfix fails even
> > > > if just one of these sub meshes does not have texcoords, but Generate
> > > > Tangents is specified.
> > > >
> > > > Chris: It seems odd to have cmodfix exit outright with an error just
> > > > because the user specified --tangents but some of the meshes don't
> > > > have texcoords. In fact I'm not seeing why cmodfix should be
> > > > categorizing the failure to generate tangents as an error at all -- if
> > > > tangents don't exist for some (or all) parts of the model does it make
> > > > the model invalid?
> > > >
> > > > Cheers,
> > > > DW
> >
>