You know something is weird when I stay up programming till after midnight for 'fun'. Yes, you heard it correctly. For fun. I am writing a VRML97 parser I am going to call TinyVRML that uses an embedded syntax generation system so I can implement an entire VRML parser in just a few hundred lines of code.
The typical VRML parser involves actually creating classes for every single one of the nodes and all of their fields. That makes sense, of course, but since one of the features of VRML is the ability to extend the language within the language, heck, why not just define the entire language that way. So, it parses a response file that defines all of the nodes, their syntax, and contents, and then you need a very small amount of code to actually parse the entire file.
This only refers to parsing the file in and saving it back out, it says nothing of actually interpreting the data in a meaningful way. That *is* a huge project and takes way too much code. However, that's not what I need to do. I just want to be able to load any VRML file, grab the stuff out of it that interests me, and then save it back out again without losing any of the other bits I don't care about. That's pretty straightforward to do.
I don't intend to preserve comments, but I don't think you are required to do so anyway. This all started when I wrote an extraction tool for my old game Scarab over the weekend and I exported all of the game levels in VRML format. I could bring them up in a VRML viewer, which was really cool, but what I *really* want do do is load them up and walk around in them. Of course I don't have to use VRML, but there are actually no appealing alternatives out there anyway. When I get my level loader written, so I can load a level and walk all around it, I can also export level data from Quake, Unreal, HalfLife, and lots of other games for testing purposes. The more data the better. I am just trying to make a really cool demo framework for interacting with virtual environments is all.
I guess I should go to be now, but it was certainly 'fun' writing this parser that feels like self-modifying code.
The typical VRML parser involves actually creating classes for every single one of the nodes and all of their fields. That makes sense, of course, but since one of the features of VRML is the ability to extend the language within the language, heck, why not just define the entire language that way. So, it parses a response file that defines all of the nodes, their syntax, and contents, and then you need a very small amount of code to actually parse the entire file.
This only refers to parsing the file in and saving it back out, it says nothing of actually interpreting the data in a meaningful way. That *is* a huge project and takes way too much code. However, that's not what I need to do. I just want to be able to load any VRML file, grab the stuff out of it that interests me, and then save it back out again without losing any of the other bits I don't care about. That's pretty straightforward to do.
I don't intend to preserve comments, but I don't think you are required to do so anyway. This all started when I wrote an extraction tool for my old game Scarab over the weekend and I exported all of the game levels in VRML format. I could bring them up in a VRML viewer, which was really cool, but what I *really* want do do is load them up and walk around in them. Of course I don't have to use VRML, but there are actually no appealing alternatives out there anyway. When I get my level loader written, so I can load a level and walk all around it, I can also export level data from Quake, Unreal, HalfLife, and lots of other games for testing purposes. The more data the better. I am just trying to make a really cool demo framework for interacting with virtual environments is all.
I guess I should go to be now, but it was certainly 'fun' writing this parser that feels like self-modifying code.
Comments