Skip to main content
GameDev.net gamedev.net
🔒 Locked

File export setup (high level thoughts)

Started by duhroach Nov 4, 2004 at 9:36 AM 4 replies 500+ views
Original Post
duhroach
duhroach
So, the base of my graphics engine has been completed. I can successfully create and render all the various objectes needed in an engine. The next logical step of course, is then to write a plugin, so i can export data from a 3d program (Maya) to my engine. Here's the issue: What is the better path to choose when writing a resuble interface for import/export of a 3d scene? Two options have I've come up with: 1) Go oldschool: Have the plugin directly write the data to the file. Pros: Fast & easy. Doesn't require engine/game interfaces. Cons: Doesn't allow for 'unified' file IO. Easy to cause errors. 2) Create a 'write' method for my scene class (read already exists) Pros: Unified IO. All plugins just add data to the scene, scene writes it. Easy to make changes that effect multiple plugins. Cons: Would need to create "accessor" classes to get to needed data for each type (primitive, texture etc). All plugins would have to minimally load the graphics engine in order to get the operational handles. Now, i'm really wondering which is the lesser of the two evils here. On one hnd, you've got a fast solution, but requires alot of upkeep in the longrun. and at the same time, doesn't require alot of interfacing with the engine. While on the other hand, you've got alot of work up front, low upkeep in the long run, but a HELL of a lot of code for accessor functions. Also, there's the fact that each plugin will have to load a minimal device from the engine in order to create the objects. I was wondering if anyone has thoughts on this, or if you would like to comment. ~Main
lubby
lubby
I would go your second choice, unless you have a format set in rock, and you plan to stick to it. After coding several exporters for various formats using your first method I ended up basically recoding the whole lot for another export format and sometimes only updating an existing format. The whole point of your post was for a resuable interface and the second option is basically just that.
duhroach
duhroach
Thanks for the reply lubby.

So you don't see any problems with the interface classes, or the fact that the plugin would have to essencially load a d3d device before exporting every time?

thanks for the input!

~Main
lubby
lubby
I dont see any issues with minimally loading your engine while exporting. Unless you intend for the exporter to be usable on a box without directx, Mac/*nix. Some of the more modern export and asset management tools do this already. See Doom3 and Unreal toolkits for some examples. I think you have a good idea so run with it. The time spent implementing the accessor methods will pay off in reasonably short to long term productivity.
zahadam
zahadam
Hey. I'm a fellow Maya user, and I am very interested in your new mothod of exporting. Get in touch. elderoth@hotmail.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.