G3D SDK, Ideas Needed!

#1 Tom,

Sounds great!

I would love to get access to the G3D SDK when you feel comfortable releasing something, even if it is still rough around the edges.

When I model my programmer-art I do it mostly in a simple in-house tool that uses DirectX .X files as a native format and I'd love to make a .X -> G3D convertor to make my life easier.

This could potentially be useful to other people as well in a similar way to the proposed 3ds convertor, since many existing modeling packages can write DirectX .X files.

#2 Tom

Sounds like all the items you have planned are good to go. The standalone converter would be great for 3ds for people like me who does not have 3DS, and can't afford it, that way we can download models from the web and use it.

I like your concentration in Milkshape, since this is a "hobbyist" engine, Milkshape would be the way to go as most people doing this as a hobby can not justify spending the cash for 3DS/Maya or other high end tools for modeling. I mean I wish I could but I am not going to charge something to my CC that I may not pick up, its hard to keep up with programming :)

I wish I could comment on the limitations and annoyances you see in the G3D format. As I do not know the format I can not tell you.

When you release your SDK I would look into writing the standalone converter. I had semi success writing a Maya to DTS exporter, couldn't get the texture mapping to work, just the overall shape of the object. But since I code in MFC for a living I can get the front end going :) I will look into it more when you release your G3D SDK.

Thanks for the work!

#3 @George,

Is the email address in your profile valid? If so, I'll email you details. There's a build from a couple of days ago lieing around that I did for the re-dev mailing list. Note, though, that it is rough around the edges and it's not guranteed to compile "out of the box" since my compile settings are different (mostly just the runtime libraries I use, but there may be some hard coded paths, especially in the test stuff). It does need RE, but only for the Array template currently.

A .X converter would be very useful, dont know why I didnt think of that :)

@Sam,

Yep, Milkshape support is sorely lacking from the current RE, hence why I started work on it. The G3D SDK was borne from that idea since I needed it to make the exporter easier to write and more future proof.

The DTS file format is a lot more complex then the .g3d format, which may not of helped you much. Perhaps with the G3D stuff it will be easier. If you want to have a go at it, let me know and I'll email you the info too.

@All,

Since RE will be (soon, the work's being done) portable, I'm inclined to make the entire G3D SDK portable. This means: converters should be command line based and not use any OS specific APIs. However, a Win32 front end app that just runs the converter would be fine. The only exception is exporters, which are obviously platform specific. This restriction isnt that bad, it just means you have to stick to the standard C or C++ library, which is all you really need for a converter.

Tom.

#4 @Tom I would love to take a stab at it. DTS was very difficult and MAYA was difficult as well sine you had to use their API instead of writing the file out. But if you don't mind I will take a stab at it, since this engine could be the entry level for a lot of people, and if we can get 3DS to work in it, it would be great. Please feel free to email me at sam@stuffsoft.com and I will get to work on it tonight when I get home and if you don't mind ask you any questions you may have. But I am eager to contribute to this engine and your work any way I can.

Once the engine is done I can make it command line. Now that I know that I will stick to normal c++ calls and use the STL for anything I may need, thinking vectors. But I would not be able to cross compile as I only have Wintel boxes, oh I am getting my hands on a Linux box but that maybe a bit out as I have other plans at the moment, and can get to setting it up when I can.

#5 Yep, gfm@yahoo.com is a good place to reach me by email.

As far as portability goes, the .X->G3D conversion util I'd like to do in the near term would not be portable, at least not in its initial version. Currently when working with .X files I use the D3DX Mesh APIs to handle file parsing and then I work with the data through D3DX/D3D. For obvious reasons this method will not port directly over to Linux. However:

1) The .X file format is well documented, so there exists the possibility that this could be changed in the future by adding a portable .X file parser into the converter.

2) The .X file format is kind of a special case anyway, IMO. While most Windows-based modeling tools have some support for it now it is far less likely to figure into the conversion path for someone working with Linux or any other non-Windows OS.



In short, I do agree with the general idea to keep things portable but there is a huge convenience in using the existing D3D/D3DX APIs as opposed to writing (testing, etc) a portable parser for the format and at this current point in time I don't have enough free time to implement the converter in the fully portable way, though I could knock one out pretty quickly by cheating and using the D3D APIs in conjunction with your G3D SDK.

#6 Hi all,

Wow, do any of you do any work at your day jobs?

Tom, thanks again for spearheading the exporter issue. It certainly is a barrier for the "hobbyist" and having the Milkshape exporter should really help.

A word about Documentation/Style/Audience
I am of the opinion that anyone interested in writing exporters automatically discredits themselves as a beginner ;) So I am not nearly as concerned about the Audience for the exporters.

Most people using the RE SDK probably won't be perusing the G3D SDK and exporter code so matching my "documentation style" is unnecessary.

That said, DOCUMENT YOUR WORK!

Sanctioned Work
I'm going to "sanction" certain work to be directly included in the RE SDK. Tom's G3D SDK and Milkshape exporter are being included as a sanctioned work. Other work, for example a less popular exporter with little documentation, may not make the cut as for the RE SDK.

However, I will provide server space to host all this work as it comes in. I want to keep the RE SDK download small and accessible. I also don't want to complicate the RE SDK development environment unnecessarily. So any descisions about what to include in the RE SDK packet and what to host on the website, will be on a per work basis.

Command-line vs. GDI wrappers, etc.
The original thought on this has always been to create command-line standalone apps that could be integrated into a game or used as a standalone converter. I'm also a huge fan of GDI wrappers and I think they have a real place for the beginner.

So ultimately I'd like to see small converter libs which can be linked into applications. And a series of small command-line apps (or one all encompassing app) that is portable. Optimally a GDI wrapper around all the small converters to tie them all together in a nice user friendly utility. Of course this GDI wrapper is platform specific.

Make it so!
The original thought was to get the Milkshape exporter out first then release a 3ds->g3d converter. Most modelers support the 3ds format so at least you can save your models to a format that can be converted.

That said I don't want to discourage anyone from writing converters for whatever format and platform they need and I'll certainly host them (when I finally get the website up!)

Can't wait to see what you all come up with.

Chris

BTW For those new to the community we have a limited access development CVS repository setup which might help develop these sort of exporters. You need to sign up for the RE SDK development mailing list at drunkenhyena.com/mailman/listinfo/reaction-dev_drunkenhyena.com to get information on the CVS repository.

#7 Bloody hell, this is ballooning ;-)

@Sam,

Couple of things: if you're only using vectors, avoid the STL. RE has an Array class which is roughly equivalent to STL's vector, so just use that. There's problems linking code that uses the STL to RE (there's a workaround, but it involves disabling the debug memory allocator, which requires a special build of RE, which means it would require people to not use the debug allocator which'd make it kinda pointless).

If you're using Maya's libraries to read the Maya file format, that'll effect portability. But, if the file format is complex and theres no docs on it, you probably dont have much choice. Same thing as with the .x stuff really. Take the easy route for now to get something running, then it can be rewritten later if needs be.

@George,

Forgot about that :) No worries. The .x format can get complex, use DX for now and worry about portability later. Like you say, though, it may not be an issue.

@Chris,

Day job? What's that ? :)

Want me to manage the whole exporter/converter project? That'd take some of the load off you and I know where you want things to lead so it wont be a prob.

Docs: Just a reminder that the actual program (converter/exporter) needs end-user docs which should be beginner friendly :)

Command Line: The "easiest" short term way of doing this is have the command line app. The wrapper can just call that, and display the results in a log window, much like the VC++ IDE does. I hadnt considered libs, that would be a fairly easy thing to do too. One path for this is to subclass the G3D SDK classes for each file type to give one consistent interface. I think I might make a minor redesign to allow this to be done easier.

I think initial effort on all converter projects should be in the command line area. The GUI should wait til the command line version is done or mostly done. Since most of the interfaces to the converter would be standard, we may get away with a single GUI wrapper. I'll have a look into that, actually.

"Make it so": That's still kinda the plan, at least for me. I wasnt expecting so much interest in the SDK itself before it was finished, and I'm quite happy to assume a project manager role and help anyone start work on their own converters/exporters. The G3D SDK is sort of ready for it, it's just rough around the edges and the Milkshape stuff is holding it up. This will help me clean up the API, too.

@All,

Portability

Perhaps I emphasised it too much. What I meant was that where possible you should program with portability in mind. Don't bother testing it on a *nix box at this stage. This basically means, stick to stdlib and RE, and try to segment off anything that is OS dependant. This wont always be possible, but commenting code where portability is an issue will save us time later.

RE also has a lot of stuff built into it that you can use. For example, Array and IO_FILE.

It would also help if you all started using the CVS version of RE. We'll get things done a lot quicker that way, especially when I get round to integrating with RE, since that'll all be done through CVS.

I've probably forgotten loads. I'll get emails away to you now with the current build of the G3D SDK.

Tom.

#8 @Tom thats fine, I was going to work on the 3ds to g3d converter. Heck it maybe simpler with the plugin already written for it and us having the source code :) If you want me to work on it that will be fine as I would be happy to do so. Also, I will stay away from STL didn't know there was a problem with using it in RE. Let me know when you have your end up and I will start to code unless there is another tool someone knows of that they would like an exporter for. MAYA yes I was using their API my friend had the student edition and was unable to find any docs on the fileformat so we had to use the API to traverse their node style file format.

@Chris Well I am always learning :) The day I say I am an expert or content with the knowledge I have is the day I stop breathing. Also, I am typing this from my day job :) Its nice being MIS Director for a small company I can do a lot of things and not be away from the Net. Btw, was 1.2 released yet? =) **UPDATE** Nevermind saw your post in the other thread... Hurry up beta testers! :)

#9 I will volunteer to create a terrain engine for RE. Is that something that people would want?

Clint

#10 @Clint it could be. I am thinking of adding a terrain engine for my use, but as Chris said he doesn't want the engine to be the scale of TGE. I was just going to use a brute force terrain as my game is small (want to do a tank game) and doesn't need to page in terrain information or LOD. But I already know several people have shown interest in this area and if you want to do it "go for it" :)

#11 @Sam - It was just an idea. I have a couple game ideas that will need a simple terrain engine.

I am also planning a space combat game as well. That is what sparked my question about 3d models, specifically the one from Bravetree.

Again, if no one else has started a terrain engine I will very soon.

#12 @Clint I wasn't putting down your idea. I mean if you want to write one, heck I would use yours instead of writing my own=). I am just saying several people have shown interest and maybe interested in it as well. I was just thinking of writing a brute force one where it just renders every triangle to screen with no optimization for the terrain in my game, but if you come up with a nice method put my email down and let me know when you finish I would be more then happy to use yours! =)

#13 @I didn't take it as you were 'putting down' my idea.:) I just wanted to throw that idea out and see what happened.

I don't think that I could make a terrain engine at this point that could rival Torque's anyway.. I know that I can do a simple one and it would be fun.

#14 @Sam,

I have the 3ds -> g3d converter pretty much covered. Matt Fairfax gave me some 3ds loading code when we were trying to get normals to work in the MS3D exporter, he kindly gave permission to use it for the converter. Therefore, it should be a short couple of hours job to get a converter running. I don't have any code that can load 3ds animation stuff, though, so there will be a need for someone to do that.

That reminds me, I forgot to send the emails, sorry.

Tom.

#15 @Clint exactly thats where I feel this engine is great is in its simplicity. If people wanted a terrain engine like TGE then they should buy TGE. I think the market is in small games. If 3-4 man dev teams think they can make something big so be it, look at riseofpower.com that looks great. But for people who want to put a game down in their resume then I am going to bet on RE its nice I own a few engines (TGE, RE, PowerRender) and I like the simplicity and the documentation of what Chris is putting together. Small games will always be around "us" hard core gamers know that its in the gameplay and not the "eye candy". Remember when asteroids was fun? Or, defender? There was no big story behind those games drop in your quarter and play, or even Joust? Those are the kind of games I wish to recreate hopefully in 3D and I am betting people will be willing to pay, as most of the people who remember those games are around 30 now :)

#16 @Tom well someone also recommended a AC3D converter so I will look into that as well. I will give animation a shot, are we just talking straight keyframe animation or are we going to bring in the bones and vertex weights for ingame IK (don't know if the engine supports this)?

#17 Sam,

The engine doesnt support bones etc. Only keyframe, material list and visibility. The G3D SDK does have stuff in for animation, and it should work, but I havent tested it yet.

The trouble with the 3ds file format (according to Matt's comments) is there's so many different ways to animate, he didnt bother doing it for his viewer app. I dont know enough about the format to really comment on it other then hearsay.

Maybe adding support for bones would be a good idea. As an interim it may be possible to put it in the G3D SDK and have that create mesh deforms based on bone animations. I'll have more figured out once I've put animation in the MS3D exporter, since this is an area I havent looked into much yet. My immediate need was for static shapes and thus that got done first.

Tom.

#18 Is the reaction dev list still active? If so how do I sign up since drunkenhyena has not responded to any of my activation. If not if not is there any place I can find out about the activity of RE.

Thanks
Dave

#19 Chris Cole is in SF and thus any offical/supported dev from Monster Studios is on hold, the community has seemed to die off as well. I still use RE and there was a resource released not to long ago to resolve a known alpha issue.



Best bet would be to post to the RE forums and those of us in the know will help when and where we can
-Ron

#20 Thanks Ron

Mainly just looking to see if there is an updated Milkshape exporter right now.

Dave