TSE orkbase into Cartography Shop?
by Tim Betts · in Artist Corner · 03/09/2005 (7:07 am) · 26 replies
Sorry, wasn't sure where to post this, but has anyone gotten the orkbase from the TSE example into Cartography Shop? I've been trying to do it as an educational exercise, however, it's given me a whole bunch of problems. Here's what I've tried so far. Please forgive me inexperience with QuArK as well, since I'm a newbie and I'm planning to use Cartography Shop for all my mapping. Here's what I've tried so far -
Load up TSE Test Objects.qrk since they have not been added to the Texture Browser. However, if you switch to the 3D textured view, you'll see that none of the textures are applied.
Open Texture Browser and Import all textures in this directory. They are mostly PNG. If you click through each one in the browser you'll see that the majority have gotten imported correctly, however, the exception appears to be the normal maps and a couple of others. You can ignore the normal maps since I understand these are only used by TSE and not by QuArK.
I then switch to the 3D view I can see all the textures applied, however, their scale and positioning looks nothing like they do in the TSE demo? Why is this? Perhaps this is an old version of the QuArK map?
Anyway, I then choose "Prepare used textures" and "Export Valve 220" to get the textures and map file from QuArK. I then open the map in Hammer and re-save the MAP just to make sure.
Now the touch part. It looks like the only way to get the MAP into Cartography Shop is to use the MAP to CSM utility, unfortunately, this requires a WAD file to be built. So I use Wally to create a WAD3 file which contains all the textures. However, this cannot be done unless you manually rename the corridor_trim and other file names (including the their references in the MAP file). If you don't do this, Cartography Shop will crash if it can't find all the textures specified.
I've since moved onto other things, but I wonder whether all this is necessary or whether there is some massive shortcut that I've not clued into yet or maybe some kind soul has already done this. It's been an education for sure.
--Tim
PS. Can I grovel to anyone who has the TGE FPS example ported over to TSE, but something I should probably do myself, unless there is a better starting point for a FPS anywhere. Thanks.
Load up TSE Test Objects.qrk since they have not been added to the Texture Browser. However, if you switch to the 3D textured view, you'll see that none of the textures are applied.
Open Texture Browser and Import all textures in this directory. They are mostly PNG. If you click through each one in the browser you'll see that the majority have gotten imported correctly, however, the exception appears to be the normal maps and a couple of others. You can ignore the normal maps since I understand these are only used by TSE and not by QuArK.
I then switch to the 3D view I can see all the textures applied, however, their scale and positioning looks nothing like they do in the TSE demo? Why is this? Perhaps this is an old version of the QuArK map?
Anyway, I then choose "Prepare used textures" and "Export Valve 220" to get the textures and map file from QuArK. I then open the map in Hammer and re-save the MAP just to make sure.
Now the touch part. It looks like the only way to get the MAP into Cartography Shop is to use the MAP to CSM utility, unfortunately, this requires a WAD file to be built. So I use Wally to create a WAD3 file which contains all the textures. However, this cannot be done unless you manually rename the corridor_trim and other file names (including the their references in the MAP file). If you don't do this, Cartography Shop will crash if it can't find all the textures specified.
I've since moved onto other things, but I wonder whether all this is necessary or whether there is some massive shortcut that I've not clued into yet or maybe some kind soul has already done this. It's been an education for sure.
--Tim
PS. Can I grovel to anyone who has the TGE FPS example ported over to TSE, but something I should probably do myself, unless there is a better starting point for a FPS anywhere. Thanks.
#2
03/09/2005 (8:10 am)
That would be just awesome Tom. It would certainly cover all the bases and I would imagine encourage more people to use the Cartography Shop pipeline too :). I would imagine its not worthwhile for a DIF to CSM though too.
#3
www.apexnow.co.uk/tools4.htm
03/11/2005 (12:49 am)
Also, you might try this one and see if it works...www.apexnow.co.uk/tools4.htm
#4
I would just prefer that it was flexible enough, not to have to be used with a WAD file and instead just let me tell it where to find the textures. Would have been very useful in a situation like this where you have the MAP file, but no WAD file and the textures were created without the 16 character WAD file name limit. Would be a flexible option.
The other case where that option would be useful to me is when I have a complex interior that would be far easier to model in Lightwave and bring into CSM. In this case I use the LW-to-MAP utility from Greenbrier to create a MAP file, but I still have to re-save it's MAP in Hammer into Valve 220 format before I can use the MAP to CSM utility and then again there's the issue of the WAD file not being a WAD3 file, etc., etc.. Oh, well.
Anyway, I'm forgive my rambling. I haven't decided how much I'm going to pursue trying to get this art-path from Lightwave -> MAP -> CSM working at this point. If I get some reliable process working, I'll post how to do it. I wouldn't be surprised if I'm just not going about the tools in the right way.
-- Tim
03/11/2005 (4:39 am)
Thanks Ed, but that was the MAP to CSM utility I was referring to above. I would just prefer that it was flexible enough, not to have to be used with a WAD file and instead just let me tell it where to find the textures. Would have been very useful in a situation like this where you have the MAP file, but no WAD file and the textures were created without the 16 character WAD file name limit. Would be a flexible option.
The other case where that option would be useful to me is when I have a complex interior that would be far easier to model in Lightwave and bring into CSM. In this case I use the LW-to-MAP utility from Greenbrier to create a MAP file, but I still have to re-save it's MAP in Hammer into Valve 220 format before I can use the MAP to CSM utility and then again there's the issue of the WAD file not being a WAD3 file, etc., etc.. Oh, well.
Anyway, I'm forgive my rambling. I haven't decided how much I'm going to pursue trying to get this art-path from Lightwave -> MAP -> CSM working at this point. If I get some reliable process working, I'll post how to do it. I wouldn't be surprised if I'm just not going about the tools in the right way.
-- Tim
#5
Another way might be to make a LWO (or whatever) importer for CShop... but I'm not sure how difficult the LW format is to parse...
@Tom: I know your working on a CShop->Torque path but I'm not learned up on it enough yet to realize what's going on. Do you have a "straight from CShop to DIF" path in the works, with lightmaps made by CShop and all? If so, I'd like to pick your brain on how you're going about it. A gile[s] to DIF path would be even nicer... ;-)
03/11/2005 (6:40 am)
@Tim: What is the end goal you're trying to achieve in this path from LW to CShop? It should be easy enough to make a .MAP import plugin for CShop (for LW exported MAP files at least, assuming they're very close to Q2/HL format or Q3 format), but I'm not sure why you'd want to do this... since to get back to Torque, you have to export as .MAP again, and deal with the little nuances of making that work, etc.Another way might be to make a LWO (or whatever) importer for CShop... but I'm not sure how difficult the LW format is to parse...
@Tom: I know your working on a CShop->Torque path but I'm not learned up on it enough yet to realize what's going on. Do you have a "straight from CShop to DIF" path in the works, with lightmaps made by CShop and all? If so, I'd like to pick your brain on how you're going about it. A gile[s] to DIF path would be even nicer... ;-)
#6
What i did, with GGs blessing, is move a modified version of the map2dif code into the DLL exporter plugin. It's worked so far, but it has serious issues as map2dif code has *alot* more uninitialized vars and uncleared data caches than i expected. I also protected it all with some catch all exception handlers as map2dif loves to crash when it's unhappy with your data.
So i'm gonna hack the memory allocator to return zero'ed memory which should instantly make the map2dif run the same from one execution to the next. I need to remove all static vars and add some more message pumping into the lighting loop... it currently locks up the UI when it's processing lightmaps. All hacky fixes... but it will work.
03/11/2005 (10:42 am)
@Ed - Yes i'm going right from CShop to a DIF... no command line junk... it even copies and converts the textures over for you. Aside from a few bugs to work out next week it's been pretty successful. It currently doesn't export the CShop lightmaps, but it's on the list of things to do.What i did, with GGs blessing, is move a modified version of the map2dif code into the DLL exporter plugin. It's worked so far, but it has serious issues as map2dif code has *alot* more uninitialized vars and uncleared data caches than i expected. I also protected it all with some catch all exception handlers as map2dif loves to crash when it's unhappy with your data.
So i'm gonna hack the memory allocator to return zero'ed memory which should instantly make the map2dif run the same from one execution to the next. I need to remove all static vars and add some more message pumping into the lighting loop... it currently locks up the UI when it's processing lightmaps. All hacky fixes... but it will work.
#7
It's amazing how massive the code is for map2dif... and it borrows a great deal of code from TGE itself into its EXE. :-(
How do you think this will all work for people wanting to use this tool path in conjunction with the Torque Lighting Pack?
I'm sure there'll be lots of users that will be happy to have this tool path. And, it'll open up the way for other exporters for other tools. For example, if it all works out, I'd like to make a version that will work with gile[s]. :-)
03/11/2005 (11:18 am)
Wow... that's a big job! I remember looking at doing the very same thing and thinking, "Hmmmm... that'd be a BIG job...". ;-)It's amazing how massive the code is for map2dif... and it borrows a great deal of code from TGE itself into its EXE. :-(
How do you think this will all work for people wanting to use this tool path in conjunction with the Torque Lighting Pack?
I'm sure there'll be lots of users that will be happy to have this tool path. And, it'll open up the way for other exporters for other tools. For example, if it all works out, I'd like to make a version that will work with gile[s]. :-)
#8
This will be a real boost to the community folks like myself who are not old school QuARK addicts. Milkshape + Cshop = my friends ;)
Thanks and good luck.
Mark
03/11/2005 (11:56 am)
Tom - Thanks for doing this. Awaiting your results. I attempted QuARK >> DIF 3 times in the past and between the learning curve of QuARK, crashes, stability, and MAP2DIF issues it was more than I was prepared to bite off at the time. Last night I loaded up Cshop and in 15 minutes I had an interior structure built, skinned, lighted and ready for export.This will be a real boost to the community folks like myself who are not old school QuARK addicts. Milkshape + Cshop = my friends ;)
Thanks and good luck.
Mark
#9
The next beta, if all goes well, will be the last beta before we officially release this thing.
03/11/2005 (4:24 pm)
@Ed & Flybynight - It was all actually much easier than i expected really and it served a great tool to learn some basic Torque engine structure. I'm still learning what the lighting pack will do for me myself, but once it supports TSE i'll surely think about how it can be integrated.The next beta, if all goes well, will be the last beta before we officially release this thing.
#11
03/12/2005 (9:03 pm)
You can get the latest from our website and I will announce in this forum when the new beta is up.
#12
03/12/2005 (9:56 pm)
Thanks Tom!
#13
05/23/2005 (11:17 am)
Just wanted to let people know that the 1.1 version of Pipeline will have Valve 220 .map import. I'm using the orkbase to test it.
#14
05/24/2005 (5:19 am)
This is awesome news Tom. This feature will be so useful to me. I assume you'll make an announcement in this forum when 1.1 is available. Cheers -- Tim.
#15
05/24/2005 (6:12 am)
That is great ! I had done a lot of map that will be happy to get "Cartografyed".
#16
Cartshop loads the available textures at startup only. I originally planned to automatically copy textures from the map path into the CS texture folder. I'm doing this now, but CS won't see them until it's restarted.
So my choices now are:
a) just make it a requirement to do the import twice... once to move textures, restart, then again to get it all in final form. This totally sucks.
b) don't do texture copying at all and let the user re-texture things as needed. Not as lame as A, but lame non the less.
c) Make the importer a stand alone EXE and remind the user to restart Cartshop after running it. This IMO is just as lame as B.
So i'm sort of stuck on which is the best of all these bad choices i have. =(
05/28/2005 (9:39 pm)
Ok... small hiccup in the importer which i want to get community feedback for before i proceed.Cartshop loads the available textures at startup only. I originally planned to automatically copy textures from the map path into the CS texture folder. I'm doing this now, but CS won't see them until it's restarted.
So my choices now are:
a) just make it a requirement to do the import twice... once to move textures, restart, then again to get it all in final form. This totally sucks.
b) don't do texture copying at all and let the user re-texture things as needed. Not as lame as A, but lame non the less.
c) Make the importer a stand alone EXE and remind the user to restart Cartshop after running it. This IMO is just as lame as B.
So i'm sort of stuck on which is the best of all these bad choices i have. =(
#17
My 2 cents.
B--
05/28/2005 (9:43 pm)
Tim: The lesser of 3 evils seems 'A' : Import/Restart/Import. Simple.My 2 cents.
B--
#18
The closing and reopening of Cartshop to add new textures already annoys me :/
When you are making something and you suddenly think of a texture you have that would look good only to realise that you havent actually got it in Cshop. It spoils the flow a bit as only the perspective window remembers where it was and your grid sizes all reset to 32. Just getting back to where you where working can be a trial on a large map.
Personally, in terms of workflow, having both B and C would be ideal. If you just want to bring in some standard geometry which you are going to retexture anyway then import from inside Cartshop and carry on working. If you know you are going to use a pre-textured object then run the stand alone first and then open Cshop.
Option B would be good if you could specify an existing default texture to use. For example a plain one you may be using when testing difs as you build them or possibly the null one so you only have to texture the faces that can be seen without having to go looking for hidden faces to put null on manually which is a pain when you are doing it thoroughly.
IMO, if I really had to choose just one option, I would go for B as I can see me mostly using it for bringing in standard geometry as I am making the dif.
05/29/2005 (4:31 am)
@Tom - A difficult choice.The closing and reopening of Cartshop to add new textures already annoys me :/
When you are making something and you suddenly think of a texture you have that would look good only to realise that you havent actually got it in Cshop. It spoils the flow a bit as only the perspective window remembers where it was and your grid sizes all reset to 32. Just getting back to where you where working can be a trial on a large map.
Personally, in terms of workflow, having both B and C would be ideal. If you just want to bring in some standard geometry which you are going to retexture anyway then import from inside Cartshop and carry on working. If you know you are going to use a pre-textured object then run the stand alone first and then open Cshop.
Option B would be good if you could specify an existing default texture to use. For example a plain one you may be using when testing difs as you build them or possibly the null one so you only have to texture the faces that can be seen without having to go looking for hidden faces to put null on manually which is a pain when you are doing it thoroughly.
IMO, if I really had to choose just one option, I would go for B as I can see me mostly using it for bringing in standard geometry as I am making the dif.
#19
Or myabe i'm missing something.
05/29/2005 (11:48 am)
@David - I've noticed your use of the null texture on hidden faces. As far as i know that isn't nessasary in Torque. If you stick two blocks together and export them you'll notice that the exporter reports that it exported 10 surfaces insted of 12. Putting the null texture on those hidden inner surfaces doesn't seem to effect the DIF at all.Or myabe i'm missing something.
#20
05/29/2005 (12:45 pm)
@Tom - Hmm ... more likely its me that has misread something :(
Associate Tom Spilman
Sickhead Games