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.
#22
I think i'm gonna just not do any texture import for now for two reasons. One i can't get it to work how it should. Two i need to move on to other projects at this point. If the textures are already in the texture path Cartshop will find them, but if not it will give you a warning and assign the default AlgeaBricks texture. Still the UV mapping will all be correct.
05/31/2005 (11:31 am)
I actually have Josh's ear with alot of things we want to see in Cartshop5, so i'm fairly confident i can get this issue fixed. CS4 will not see any new changes at this point.I think i'm gonna just not do any texture import for now for two reasons. One i can't get it to work how it should. Two i need to move on to other projects at this point. If the textures are already in the texture path Cartshop will find them, but if not it will give you a warning and assign the default AlgeaBricks texture. Still the UV mapping will all be correct.
#24
Still in cases where both brush surfaces completely obscure each other i don't think using a NULL texture helps any. At least i haven't seen a measurable change in the DIF produced.
06/02/2005 (6:59 pm)
I seem to read that as a way to get the benefits of a detail brush on a per-surface basis. Like in the case shown in that link since the bottom of the column has the NULL texture it will not split the ground plane.Still in cases where both brush surfaces completely obscure each other i don't think using a NULL texture helps any. At least i haven't seen a measurable change in the DIF produced.
#25
06/03/2005 (10:12 am)
Well at least its good to know I dont have to spend ages flying the camera through brush faces looking for things I havent NULLed :) 
Torque Owner EddieRay
I'd suggest that you don't go to any "extra effort" to avoid the "have to restart it to refresh its texture list" problem with CShop.
Okay... enough of my whining about the poor design of CS...
Solution 1) Require the user to set up the CShop default texture folder to point to the parent folder of the MAP files (in the TGE way). Don't copy the textures at all. CS should be able to see the parent folder and all sub-folders... so if this is something like example/starter.fps/data/interiors the user should be good-to-go. This is probably the easiest/cleanest solution for you, and for TGE'ers and general. When changing projects, a user will need to change texture folders in the CS config. I'm not sure if CS supports more than one "base" texture folder... which could help here. Still... it's a "static" view of the texture folders having more than one won't solve the "refresh" problem.
Solution 2) Make your converter into a standalone program that converts to CSM and copies the texture files to a "tge" folder (or similar) under the CS "textures" folder, and copies the CSM file to the "maps" folder - all according to what setting the user desires. In my gS->CSM exporter, I allow the user to export to either the CS "textures" folder or a child folder of that one (using a terrible hack to make sure the parent folder name is "textures" - since there's no way to determine where the CS install folder is). When CS loads a CSM, I think it will correctly load all texture files, even if they have been copied to the "textures" folder after CS was already running (you may want to double-check this, but I think this is true - kinda funny that this works isn't it?).
Solution 3) Talk to Josh... get him onboard to support you (a significant contributor to his program) and plead with him to make CS work the way the users WANT it to work. I made an exporter to support his program, as kind of an experiment to see if he'd even acknowledge the effort... so far (over a year now) he hasn't bothered. For some reason, I don't feel encouraged or enthused to continue supporting CS... ;-)