Im trying to finish up a project I been working on. I took a floor plan of a house in blender and made a 3D model house with windows and doors. I want to put that into openGl and be able to walk through the home but I havent been able to understand the parsing. Ive downloaded a few that people have created and all of them have errors. Is there any way someone can help me understand the parser or know of where i can get one just to get my blender program into opengl
Create a parser for blender.obj file to use in Opengl
Is there any way someone can help me understand the parser ...
For sure. Please ask explicit questions along with snippets of code about it, if available. So we could answer your questions.
Going a slightly different route, if you do not want to do this for academic purposes (that is, your goal is to produce something that works), I recommend that you use
a) a different format (obj is pretty much a horrible format, and Blender can export much better formats).
b) Assimp. It works, and it works better that what most people can write in several weeks of time.
What format you use is up to you in the end, but for example Collada is able to much better represent not only 3D scenes but also other data that belongs to it.
The difference won't be visible on a scene with a ground plane and house with a dozen vertices. But it will become apparent once you want to go further from there and have more complex geometry, include some characters that are animated, etc. etc.
a different format (obj is pretty much a horrible format, and Blender can export much better formats).
I can only second this. From your (OP's) post, you have absolutely no requirement whatsoever for a plain text format and using one isn't going to give you anything useful for what you want to do; it'll just be a world of pain. You're far better off with something like a binary format that you can fread in a single operation (no parsing needed - yayy!) and squirt directly into a glBufferData call.
I also suggest to drop the idea of writing your own parser. It's really wasted effort and the concepts involved are of little interest in the long term. Use AssImp, as above noted.
I'll disagree with the idea of dropping investigation into writing your own parser, this is IMO and mileage may vary but:
Parsing data, and doing it efficiently can be difficult, but the lessons you learn from doing this are invaluable.
Learning the tradeoffs between string functions vs char pointer arrays, the costs of vectors vs malloc'd arrays, the various different ways of reading data, and the most important of all, how to accurately benchmark your code, were all major lessons i took away from doing parsing myself that get hidden away in the guts of AssImp and other libraries.
I of course support self improvement by writing your own parser but if you just want to walk through your house why not use the game engine packed with Blender? Just switch to blender game, make a player cube/empty, parent the camera to it and attach WASD controls and mouselook to it. Next you can design lighting and furnishing as well :)
Or Unity3D can also take a .blend file and convert it as you import it. Drag and drop the FPS controller to the scene.
Both could be used to have you WASD move and mouselook in your house in less than 5 minutes.
Writing a parser is OK if you really must write a parser; there are some concievable circumstances in which compressing/deduplicating, then parsing data makes sense.
I think one needs to look at what the OP is doing first though. He's taking a binary file format (the blender model), converting it to plain text (.obj), then parsing that plain text and converting it back to binary for drawing with. That's not a productive use of anyone's time; his objective is to draw a model and this kind of round-tripping doesn't support that objective; it's just make-work for the sake of having a parser, and parsing plain text sucks to begin with (it's slow and error-prone).
If writing a parser for the sake of a learning exercise is to be recommended, one can think of any number of better ways of going about it.
Writing a parser is OK if you really must write a parser; there are some concievable circumstances in which compressing/deduplicating, then parsing data makes sense.
I think one needs to look at what the OP is doing first though. He's taking a binary file format (the blender model), converting it to plain text (.obj), then parsing that plain text and converting it back to binary for drawing with. That's not a productive use of anyone's time; his objective is to draw a model and this kind of round-tripping doesn't support that objective; it's just make-work for the sake of having a parser, and parsing plain text sucks to begin with (it's slow and error-prone).
If writing a parser for the sake of a learning exercise is to be recommended, one can think of any number of better ways of going about it.
I agree on some levels, but I see a few good reasons for writing an OBJ parser.
For starters, it's easy. Probably the easiest model format I've dealt with. There isn't a whole lot of variation you'll encounter between exporters (watch out for negative indices!) and it will support static meshes pretty well.
It's also widely supported in modeling applications. There aren't many modeling applications that do not support OBJ, and again, you aren't hitting COLLADA style variations here.
The data is generally organized well and easily translates to graphics APIs. No, you aren't getting shaders here. Yes it's not binary. In my experience though, you are likely writing your own format, complete with your own exporters from whatever application you are using. OBJ may be less efficient, but it's a good starting off point.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement