next »

[qbproger]

Just letting you know where I'm at...

I'm about half way done with my first pass at it.  Then I'm going to make another pass and do some cleanup/commenting where necessary.  Probably not too much commenting.  Since the variable names reflect the xml tags they contain.

One thing I keep going back and forth on is as to whether, when I run into unsupported tags if I should throw a ParsingErrorException (wouldn't ParsingException make more sense?) or log it to the JAGToo logger.  I was originally doing it to the JAGToo logger, but then thought it might be better as an exception.  Now I'm back to my original thought that it should be in the logger because of how much we don't support.  It seems better to log a message and ignore it rather than having to creating a list of tags we're going to ignore (so exceptions aren't thrown).

I'll probably switch to the logger during my cleanup pass at it.

That's the latest
qb

[Marvin Fröhlich]

Yes, ParsingException would be better. But please don't rename it now, since this would cause unnecessary conflicts with my current work and I wouldn't be able to commit intermediary steps.

About the logger/exception thing: I think, your initial/last thought is the best. Keep it with the logger. People would like it to see, what is imported and rendered rather than only see an exception to be thrown and nothing is rendered.

I hope, you're not concatenating Strings for the log messages, but use the String parts as additional parameters. This is much faster.

Marvin

[qbproger]

I hope, you're not concatenating Strings for the log messages, but use the String parts as additional parameters. This is much faster.

Marvin

I'll fix this in my second pass through the XML* files.

[qbproger]

I'll fix this in my second pass through the XML* files.

I took a quick look at the Jagatoo LogManager.  I don't know if there is a need for synchronization with the StringBuffer, but according to the Java API a StringBuilder is faster and can be used as a drop-in replacement.

Here is a link to the javadoc for it:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html

[Marvin Fröhlich]

I took a quick look at the Jagatoo LogManager.  I don't know if there is a need for synchronization with the StringBuffer, but according to the Java API a StringBuilder is faster and can be used as a drop-in replacement.

Here is a link to the javadoc for it:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html

Good idea. I didn't know that class. I will replace it in the LogManager. Thanks a lot.

Marvin

[hawkwind]

log the data and perhaps provide an ability to add an Exception listener for those interested in the actual exceptions

[Marvin Fröhlich]

log the data and perhaps provide an ability to add an Exception listener for those interested in the actual exceptions

Why that? You can simply add a LigListener to the logging system with an appropriate log level filter and additionally specify the package, you want to retrieve log from. No need for additional listeners.

Marvin

[qbproger]

log the data and perhaps provide an ability to add an Exception listener for those interested in the actual exceptions

Why that? You can simply add a LigListener to the logging system with an appropriate log level filter and additionally specify the package, you want to retrieve log from. No need for additional listeners.

Marvin

I was getting ready to ask about that.

[qbproger]

I got the new parser entirely written.  Also, entirely untested, so I'll do some testing with the files in source control tomorrow.  If everything goes well I'll commit.  We'll be free from jibx.

While working on this, I found out that there is a StAX parser included with Java 6, but it wasn't present in Java 5.  I'm planning on committing the StAX API and the StAX parser.  I'm going to leave the binding.xml in there for now, as it'll be useful if problems arise.

There were some things changed about how matrices are read.  The collada spec specifies column-major as far as I can tell, the old parser did row-major for some and column major for others.

[Marvin Fröhlich]

I got the new parser entirely written.  Also, entirely untested, so I'll do some testing with the files in source control tomorrow.  If everything goes well I'll commit.  We'll be free from jibx.

While working on this, I found out that there is a StAX parser included with Java 6, but it wasn't present in Java 5.  I'm planning on committing the StAX API and the StAX parser.  I'm going to leave the binding.xml in there for now, as it'll be useful if problems arise.

Very good to know. Can't wait to see the dammit jibx out of the project. But I see no reason to let the binding.xml in the project. It will always be accessible in an older SVN-revision. So why should it remain in the HEAD?

There were some things changed about how matrices are read.  The collada spec specifies column-major as far as I can tell, the old parser did row-major for some and column major for others.

Good to know, that you're also investigating the animations and are finding bugs. There must have been something obvious in the animation code, but I couldn't find it. So, it's cool, that you're looking into it.

Marvin

[qbproger]

Good to know, that you're also investigating the animations and are finding bugs. There must have been something obvious in the animation code, but I couldn't find it. So, it's cool, that you're looking into it.

I'm not sure if it's going to fix anything.  Honestly, I'd expect it to break things because some models might have their matrices incorrect (possibly the reason for this in the first place).  I don't know anything about animations.  The majority of what I have dealt with are static models.  Anyway, things are coming along. 

[qbproger]

Aside from my other question posted here:
http://xith.org/forum/index.php/topic,1039.0.html

The new loader is mostly done (the models in svn load).  There is a good chance there are things that are broken.  I think I'll start a thread to collect any models that are newly broken (working in the very previous revision of xith) and after those are fixed, get going on new models that are sent in by people.

[Marvin Fröhlich]

The new loader is mostly done (the models in svn load).  There is a good chance there are things that are broken.  I think I'll start a thread to collect any models that are newly broken (working in the very previous revision of xith) and after those are fixed, get going on new models that are sent in by people.

This a a very good idea. It gets you the chance to get going and is a simple way to fix the loader afterwards (if necessary).

+1

Marvin

[qbproger]

The new loader is mostly done (the models in svn load).  There is a good chance there are things that are broken.  I think I'll start a thread to collect any models that are newly broken (working in the very previous revision of xith) and after those are fixed, get going on new models that are sent in by people.

This a a very good idea. It gets you the chance to get going and is a simple way to fix the loader afterwards (if necessary).

+1

Marvin

I committed my changes, should the post go in the announcements section?  If not, where?  If so, I can't post to it, so if you could do a post and let people reply/attach their models, that would be great.

[Marvin Fröhlich]

I committed my changes, should the post go in the announcements section?  If not, where?  If so, I can't post to it, so if you could do a post and let people reply/attach their models, that would be great.

You can now post to the News forum.

Marvin