New Maya2Map Exporter for 5.0 + Source!!!!

#1 But does it work? Anyone who uses it, please post your results! We have a had a lot of polygon->brush solutions before that have proven much more difficult to work with than existing brush modelling programs.

#2 Hmmm... too bad I just bought Maya 6 a couple days after it shipped :)
I'll try and compile it (sometime) anyway. Thanks for the post.

#3 How is the Maya 6 worth the upgrade?

#4 Well, I didn't buy the upgrade... I got the thing fresh and new. But the cool new features for the complete version are: soft body modification tool (means for example you select a group of verts, then move them, and the further they are away from the center, the less they move... kinda like clay), better PSD file integration (you can make layers in Photoshop for different texture layers, eg bump map, color, alpha, specularity...), better hardware rendering support, paint effects on polygons, better mental ray integration, native PNG support, general performance improvements, and some animation tools... motion retargeting (I guess it's for taking two similar skeletons and transferring the animation from one to the other... like a tall skinny guy and a midget could have the same animations).

So, they added a lot of features, and that's just the complete version. Unlimited has hair (dynamic curves), and improved fur and cloth.

It'll probably be a while before I have a chance to try this tool out, as I'm swamped with 2 jobs and school, but I'll do my best.

#5 Well you may still have to run the .map files that this thing makes thru Quark. In order to convert them to Valve 220 format. This plugin is made for going to the Q3 .map format

#6 I just tried using it in maya. There seams to be a scale issue at times but thats easily fixed. I just brought it straight from maya into quark and then exported it from there to torque. I had to clean it up a bit in Quark, but that was the model I was using not the exporter.

Getting it to work with 6.0 should be pretty easy. Unless theres been some big change to the API, you should be able to compile the source using the maya dev kit and it would work with 6.

#7 Here is is already compiled fo Maya 6
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5709

#8 I was thinking... Does the Q3 .map format support colored lightmaps like this?

Dif supports colored lightmapping it is the conversion thru the VAlve 220 .map format that ripps them out as that version of map is older and does not support them. So what is map2dif was re-written to use the Q3 .amp format insted of the Valve one?

This would make since as GG is pushing everyone to use Quark, and it is a Q3 Editor natively.
Does anyone know anything about this?

#9 Nice room, James!

Map2dif supports colored lights, afaik. So you can put in colored lights and get, in theory, that sort of effect. Did you generate those lightmaps in a q3 map compiler or in another tool?

#10 Ben it looks like its a render from a high end 3D application running Mental Ray. I think that James is using that render as a sample to help explain what he was talking about in his post (James feel free to correct me if I am wrong).

Logan

#11 I do hope you're wrong, Logan. :)

I guess what I'm getting at is, does James want to import existing lightmaps or use color in the generated ones...

#12 Actually, I believe I have seen that image before, and it is actually in-engine (don't remember which). They likely used something such as TGERad to get the soft lighting. Lightmaps allow for this kind of stuff, but it's nearly impossible to get it right manually. As far as colored lightmaps... I'm not sure whether the above pic even uses colored lightmaps. If so, it's a very subtle color. Here the main thing is reflected light... i.e. the light bounces off the floor onto the ceiling and walls and such. 'scalled radiosity or global illumination. Nifty.

#13 It was made in Carography shop and exported to Dark basic I think or Q3. I just Got an email from Stone Lance the guy that wrote the .map exporter and he said that it is in the BSP generation that the lightmaps are done. Does this mean that the stuff in torque has no lightmasp becasue the BSP step is being skiped? If not mistaken the Process is currently Maya2map EXport> Map into Quark to be modified and saved back out as HL style .map format > use ma2dif to make it something that torque can use. Is that pretty much it?

So if that is the case these are the questions I pose:

1: What can be done about this to get lightmapping of the buildings somehow from Maya "Maya can do this easily" in to torque.
2: Why Would we not want to use the Q3 .map format anyway I mean it is more modern to the best of my knowledge, and has support for things that are not in the HL .map format.
3: Will all of this be moot after the implementation of the TSE in a game? " as it would be able to add dynamic lighting making these color maps and baking useless"
4: What would be the level of work to make it so that Maya 5+ and Level Tools "Availible from the Alias website" could be used as the building editor for torque for light placement, Texturing, Everything. Then Export Straight to DIF or at least make it transparent to the user.
5: is there anyone that would be interested in working on a project like this?

#14 1) Coding =) Not that diificult if you are familiar with the subject.
2) There are two major advantages...bezier patches and texture/material names with paths. Other than that they describe the exact same geometry.
3) Baked lightmaps for static lights will still be around for a while yet
4) I still maintan that this would be of only dubious and passing value. Shoehorning a general purpose modelling package and modellers into the limitations of csg brushes will only lead to frustration.
5) There are things underway that will help make building interiors easier though for the time being it isn't focused on this track.

#15 1: ok, I personally am a 3D Artist and a project manager not a programmer
2: So why is this not in use? And does Dif support them?

3: I would imagine so as not everyone is going to have the hardware lighting capabilities.
4: Have you seen the Level Tools Plug-in from Alias? Gives you most of the features of Hammer or UnrealEd inside of Maya including the prefab library.
5: could you be a little more specific. For GG to be so secretive about what is being worked on or developed, even toward members and SDK owners seem like a really bad idea and not to mention a little counter productive. I mean if there is a level editor in the works or something that needs to be made known. And its progress needs to be reported on so that someone does not spend a bunch of time effort and money in parallel development of something. Not to mention if takes GG even half as long to make a vial interior editor as it did to get them to make shaders a priority and do something about it then we are talking well over a year. So I think that Cartography Shop 5 will even be out before GG does anything to make building interiors simpler. Of that I would almost be willing to bet money however.
Don't get me wrong new interior Editor "made by GG" should have been done a year or 2 ago I think that their ignoring of the situation "or procrastinating on it is BS. There is not an engine that I'm aware of that does not have either a level editor that comes with it or one that you can buy for less than $100. I would Drop up to $200 a seat for a Level Editor that was as nice "although scaled back" as say UnrealEd for Torque.

If you know a programmer with the skill I might even be willing to help fund the development of such a project. Because as of right now the interior builder is the weak link in my project. I hate Quark and it is the only one that we can use commercially.

#16 2) No and not directly
About a year ago I put together a q32dif app that fed Quake 3 .map files into the map2dif code and spit out a dif with a bezier patch entity included. I then hacked bezier support into the interior code on the engine-side. But I ran into 2 problems: collision and lighting...I could easily fix the first these days but the second is still a little tricky...integrating the bezier patches into map2dif's and TGE's ligthing scheme would take a bit of work. At the time I abandoned that approach in favor of loading compiled Q3 .bsp's directly. If you *really* must have Q3 .map's (w/o bezier patches) then I could put something together for you however the effect would still be the same as Maya->Quark->map2dif...you would just be skipping the Quark stage.

4) I am not even sure I have laid eyes on Maya =) Features aren't the issue...it is the limiting the artists that has to occur to get them to produce valid/compatible geometry. The second they start splitting edges or faces or creating concave geometry things get ugly fast. The have to learn a whole new way of doing things and unlearn a bunch of habits/methods they have picked up from general mesh modelling.

Quark is a bear to learn...I am very familiar with Worldcraft/Hammer, Milkshape, 3D Studio Max, and UnrealEd and I still find Quark a huge pain to use. I can definitely sympathize with you on that one =) Personally, I was planning on picking up Cartography Shop *very* soon so I could use it for my game. I know John Kabus is already testing a new cms2dif for the latest version (nothing else I will roll my own ;)

5) I am working on a license friendly interior editor built on top of Torque (thusly will support Windows, Linux, and *Mac*). The timeframe is indefinite at this point. I can't say much more than that yet.

#17 The lightmaps are stored in both valve and q3, as I understand. I think that either the Maya map exporter does not support them, or when quark reads in the q3 map, it does not get the lightmap information. If this Maya map exporter works the same as other exporters have, you won't be able to just use lights and have it work. You have to actually bake the lighting into the model _in Maya_. If I remember right (at work), it's the Prelight command. I would certainly try that before going into a big mess about rewriting map2dif for the q3 format or something similar. That failing, it would be good to try taking a q3 map that you know has lightmaps, bring it into quark and save as a valve map, then push it through map2dif and see if the lighting stayed. If that works, then you know that Maya's exporter isn't outputting lightmaps, and that's where to look. If only I didn't have 2 jobs + school + wife. Of course, I'm glad I have all those things, but they don't allow much time for Torqueing about.

I am generally more programmer than artist, though one of my jobs and half of the other say I'm more artist than programmer... anyway, I could probably look through the Maya exporter and figure out if and how it's handling lightmaps. Maybe I'll figure out some time to do that... but only if you try the things above and they don't work. I won't be much help in terms of implementing anything currently though... I've just got too much on my hands.

#18 For Quake and Half-Life the lightmaps are stored in .bsp's which are the compiled versions of the .map's (.bsp is basically the same thing as a .dif in terms of data though they have very different formats). These lightmaps are generated using the lighting entities in the .map file when they are compiled by the various tools (q3map, vrad, and map2dif).

If the Maya exporter is coughing out a .bsp then you can get the lightmaps from it (or load it directly). However, most likely it is just spitting out a .map which stores light entities but can not store lightmaps.

Pre-baking the lightmaps is a reasonable approach however you are going to increase your texture usage dramatically (thus lowering performance). Say, for example, you use the same texture on the front door and on the back door. When you pre-bake you are going to have to create two copies of the same texture with different lighting baked into them. With lightmaps you usually have a separate lightmap for every face (though they are often packed together into a larger texture). This causes less of a performance hit b/c the lightmaps generally have *far* lower resolution than a "normal" texture (Half-Life lighmaps are 16x16 for example, Quake 3's are 128x128). So either you are going to end up with a *lot* (one for each face) of high res textures + lightmaps (lower performance) or you are going to have a some really crappy low res versions of the textures (really, really ugly).

Now if you can convince Maya/Max/Cartography Shop to spit out all of the lightmaps into separate files somewhere then you are onto something. You could then skip map2dif's lighting phase and instead use the externally generated lightmaps (little bit of work but not too bad). This is an option that has been discussed a bit (I am even working on a .map->.3ds converter so that you can pull the geometry into the modeller of your choice and light it).

#19 Well, the Maya exporter is just writing out a map. As far as I can tell from looking at the code for about 20 minutes, (searching for light, vertex color, texture, etc), it appears that it does not export any lighting information. No light entities or anything. I can't possibly imagine it being too tough to include this, since .map is basically a text format... The nice thing about the Maya map exporter is that it's well done. The code is very readable, and it does a two stage export... the first stage collects lots of info from maya (for exporting different formats and such), so the lighting info is there. The second stage converts and saves to map format, where it doesn't use the collected lighting information. So we basically need to find out how the valve .map format stores quark light entities that map2dif uses. This is all of a sudden very interesting to me... I'll have to take a look maybe this weekend.

#20 @ Matt :

The Maya Level tools just that they give you a similar toolset as a say Hammer.

@John :
I love the Entusiasm!!! So lets think this out If I'm correct just getting the lighting info exported with the geometry to the .map file alone is not going to fix the situation. Well, I take that back it could but then we would have to make it to that map2dif generated lightmaps.

OR

We would have to figure out a way to make maya generate a seperate light maps and a text file containing placementor UV info. the map2dip would have to be modified to add this information and make the dif. "Prolly would want to a make a gui front end as well"

OR

Same as above but have the lightmaps and placent info stored in temp and the maya compile and export a finished .dif file
The second one would be my choice as it would allow for future support from say 3ds max or some other program.