Vrm2Egg

Pipeline
#1

Hi,
I converted a small VRML model to egg with no problem, but then all the other wrl models (which I can see with a vrml viewer) cannot be converted.
vrml2egg calims that there is an error:

Error in yt.wrl at line 1, column 0:
#VRML V2.0 utf8
^
syntax error

however, that’s only a comment and the file that works also has it.
Any ideas?

thanks.
frnacisco.

#2

Interesting.

I hate to say it, I doubt anyone here uses VRML. It may take some time until we find somebody who knows anything about this.

#3

:slight_smile:
Thanks though!

Francisco

#4

I suspect your file might actually begin with Window’s special encoding bytes: a pair of invisible bytes at the beginning of the file that indicate the encoding system used within the file.

Most Windows editors are designed to recognize these two bytes and pretend they aren’t there, so you never see them when you open the file in an editor.

You can test this by opening it in, say, Python, and reading the first few bytes yourself.

David

#5

I’m having the same problem, and there are no ‘invisible bytes’ (checked with a hex editor). I do notice that if I take my .wrl file and delete most of the Shapes in it, the conversion happens successfully. The funny thing is that I have bigger .wrl models that were generated in the same fashion as the problematic ones that convert successfully.

Looking at the source (I think the relevant file is vrmlParser.cxx.prebuilt: panda3d.cvs.sourceforge.net/view … iew=markup) it looks like the vrml2egg I have was built with verbose error messages turned off (d’oh).

If I provided one of these misbehaving files is there someone with a debug version of vrml2egg who could try to see what the problem is?

#6

Yes, go ahead and post your file.

#7

http://pastebin.com/f70119e9e

#8

Okay, I’ve just stripped that .wrl file to its essentials and it appears it doesnt chew the “1e-06” thats in there. Replace it with “0” to make it work.

I’ll look further to see if I can make it support the “e”. Yech, I’ve never worked with flex/bison/whatever.

#9

Hmm, that’s odd. The manually-pared-down file that I mentioned before still has scientific notation in it: pastebin.com/f4a60ca31

Are you able to tell exactly which line of my problem wrl file is causing the error?

#10

Nope, I can’t tell you which line a problem is. Maybe its possible but I don’t know beans about the vrml converter.

It appears 1.0e-09 parses fine but 1e-09 doesn’t. Odd. I checked the regexes that are stored in there but they match.
drwr, if you know anything about how it works, could you give me a hint where to start looking for this? At least in which file?

#11

Looking closer at the parser, it looks like it’s the lack of decimal point in the scientific notation that’s confusing it. “1.0e-06” works, while “1e-06” doesn’t. The official VRML grammar states only that it expects to find a “floating point number in ANSI C floating point format”, and checking the official ANSI C specs seems to indicate that a decimal point is optional, so this is indeed a bug in Panda’s VRML parser. It’s easy to fix; I’ll check in a fix for it.

On the other hand, the parser should have reported a more useful error message than yelling about the first line. I’ll look into that too.

David

#12

Aha. Then I’ll just do some pre-parsing of the wrl file to put in decimal points where they are missing for the time being. Thanks!

#13

Oops, simultaneous posting. :slight_smile:

For the record, it’s this line that’s causing the decimal point problem:

    /* Big hairy expression for floating point numbers: */
float (-?(([0-9]+)|([0-9]*\.[0-9]+)([eE][+\-]?[0-9]+)?))

The regexp there doesn’t allow the decimal point to be omitted.

David

#14

Huh, though that vertical bar should allow it?
This works fine:

import re
m = re.compile("(-?(([0-9]+)|([0-9]*\.[0-9]+)([eE][+\-]?[0-9]+)?))")
m.match("1e-06")

It says it either needs to contain ([0-9]+) OR ([0-9]*.[0-9]+), right?

#15

It appears that flex’s operator precedence is different from python’s re module. Flex is thinking that the ([eE][+-]?[0-9]+)?) expression is grouped with the ([0-9].[0-9]+) expression, not with the whole ([0-9]+)|([0-9].[0-9]+) expression.

Adding explicit parens solves the problem:

float (-?(([0-9]+)|([0-9]*\.[0-9]+))([eE][+\-]?[0-9]+)?)

But I’m still working on the error reporting. It looks like that was cut-and-pasted from some other lexer, like the egg lexer, and combined with a different lexer approach written by someone else; I don’t think it’s ever worked properly here.

David

#16

In case it’s of some use to someone else here is the snippet that fixes my input .wrl files:

def fixFloatingPoint(infile, outfile):
    fh1 = open(infile)
    text = fh1.read()
    fh1.close()
    missingdot = re.compile(r'(\s[+/-]?[0-9])([eE])([+\-]?[0-9]+)')
    textout = missingdot.sub(r'\1.0\2\3', text)
    fh = open(outfile,'w')
    fh.write(textout)
    fh.close()

Edit: Fixed silly mistake in call to .sub(). I was putting re.VERBOSE (which equals 64) where that method expects the count (number of matches to replace). The result was that I had to run the filter more than once on some files, d’oh!

#17

@drwr: I just updated from cvs and it works great now! The errors are reported fine now as well - if I add something invalid it prints out the erroring line. Thanks alot!