New Area Knowledge Thread

[Sithspecter]

New area creation is something of an experiment and hasn't been discussed thoroughly. The purpose of this thread is to serve as a knowledge collective of new area knowledge, and discuss what we know and don't know, and what we can and cannot do with areas at this point. I hope this thread will allow us to share our techniques and eventually allow me to write a comprehensive tutorial on new area creation.

 

For the purposes of this thread, "new area creation" refers to modeling a brand new area, not simply a module reskin. Additionally, this thread does not serve as a tutorial on how to use 3DSMax or GMax, though various techniques and functions may be discussed.

 

We've been able to create new areas for a while, ever since Magnus II released KAurora, which enabled us to compile new walkmeshes. KAurora has added several functions, including adding emitters and lightmaps.

 

1. We can create newly modeled areas

 

This one is fairly obvious, but I felt the need to include it anyways. As several members on here have already done, newly modeled areas are entirely possible. However, a new area isn't something that happens overnight. A new area takes careful planning, consideration, and a lot of hard work. Making a new area on par with existing KotOR areas will take several months of work. Area creation also entails a good amount of troubleshooting, most of which will have to be done on your own.

 

2. We can create emitters for our areas

 

KAurora also has the ability to export new emitters, for use in areas and other applications. To add an emitter, you can start by creating one from the helpers tab in Max. I have found that the best way is to base your emitter off one from the game. Pull a model with a similar emitter up in KAurora, and fill in the fields as closely as possible, changing only what you need. Additionally, not all of the fields are visible in Max, so you'll have to work on your emitters in KAurora as well. I have found that creating a model for each emitter and including them in the layout and .vis is the most hassle free. Additionally, I've had trouble getting the orientation fields set correctly. The ones that export from Max seem to screw it up when they are set at angles. For instance, when I create the steam emitters that come from the bottom of the Ebon Hawk, I always copy the orientation from the landing module of an existing planet, and everything is good. Emitters take some fine tuning, but can add a lot of detail to an area.

 

3. We can add lightmaps to new areas

 

I'd say that given the difference between lightmapped and non-lightmapped areas, it's almost not even worth it to create an area if you don't intend to lightmap it. In my opinion, lightmapping accounts for about 60-80% of how good an area looks. Disbeliever made the original, groundbreaking lightmap tutorial, which is still relevant today. Quanon's created an additional tutorial detailing the use of MultiObjectUnwrap, which streamlines the lightmapping output. Quanon and I have exchanged quite a bit of discussion on lightmaps, and we've each found different techniques that work. Quanon has found that it's best for him to do one massive lightmap of his whole area. I have found that it's best to split my areas up into small sections before lightmapping, and doing multiple lightmaps. I've also found that lightmaps are a tricky and buggy portion of the process. They take a long time to get right, and sometimes you have to start over it it's not applying correctly in the game. When finished, they are spectacular.

 

4. We can add lights to new areas

 

We've known since the beginning that AuroraDLights were possible in KAurora, though there is some confusion surrounding them. Hopefully I can help clear some of that up.

 

In the days before lightmaps, ignorant people such as myself thought that all the lighting came from AuroraDLights and Aurora Lights. It was thought, at least by myself, that AuroraDLights and Aurora Lights were 2 different things. AuroraDLights were possible to create through NWMax, but imported areas from the game through the old MDLOps 0.5 showed mostly blank dummies called Aurora Lights. New evidence from areas run through MDLOps 0.6a shows that all of these are actually AuroraDLights. So yes, AuroraDLights are possible. Aurora Lights aren't real things.

 

Lightmaps provide the lighting for an area. AuroraDLights are meant to create shadows and give light to dynamic objects such as creatures, placeables, doors, etc.

 

Quanon seems to be correct in that only 3 can light up at a time. However, you can have far more than 3 AuroraDLights in any given area. I think a common misconception used to be that there could only be 3 AuroraDLights. This is false. Use as many as you want.

 

A much more in depth explanation of AuroraDLights can be found here.

 

5. We can create minimaps for our areas

 

This one is a minor addition, and doesn't really have to do with KAurora. But, with some trial and error and a top-down render of the area, it's entirely possible to create a minimap for your area. It's a nice touch to finish up your area, even though it's not entirely necessary.

 

Here is a quick synopsis of my findings with K1 minimaps:

 

I was dreading working on the minimaps. I did one for the main street a while back, and it was a 4-6 hour trial and error process that was annoying as all get out.

 

So, I pulled up another module, rendered the top down view, and took it to Photoshop. Opened up the .are, and got ready to begin the process again. I knew that the fields in the .are were based on knowing the precise pixel coordinates on the 512 by 256 TGA of the map, and referencing actual meter coordinates of the area. However, last time I tried this, something didn't add up.

 

So I have 8 different values I have to figure out in the .are to get the map and the scaling right, based on 2 (x,y) points on the TGA and the coordinates of the area.

 

MapPt1X (TGA reference of X coordinate #1)

MapPt1Y (TGA reference of Y coordinate #1)

MapPt2X (TGA reference of X coordinate #2)

MapPt2Y (TGA reference of Y coordinate #2)

 

And

 

WorldPt1X (Meter value of X coordinate #1)

WorldPt1Y (Meter value of Y coordinate #1)

WorldPt2X (Meter value of X coordinate #2)

WorldPt2Y (Meter value of Y coordinate #2)

 

I picked out two references I could see visually on the TGA of the map, and got their meter coordinates in MAX. Filled in the WorldPt values, which was the easy part.

 

So I had figured out that the MapPt values were decimals based on how far from the top left corner the pixel representing the coordinates I just found was. For example, if the pixel was halfway to the bottom, the MapPtY for that pixel would be .5. That seemed to work fine for the Y-axis. I would figure out how many pixels from the top the pixel was, divide by 256, then I'd have the right MapPtY. The weird thing was the X-axis. This was off for the X-axis for some inexplicable reason.

 

However, I finally discovered that while the textures are all 512 by 256, the game only uses ~435 by 256 of the texture. By diving the X pixel values by 435 instead of 512, the map worked perfectly!! I did several maps right in a row, making up for the sustained time loss fighting the Great Walkmesh War of 2016.

 

6. We can use walkmeshes that are divided into multiple parts

 

Quanon probably has more to say about this, as he's done it and I haven't. But it appears that when you divide the walkmesh into multiple parts, you can rig it to work by including a doorhook line in the layout file with the coordinates of the seam between the two. This should enable us to create areas that utilize the full functionality of the vis file and multiple AuroraDLights.

 

7. We can block line of sight and blaster fire with walkmeshes

 

When I looked at the existing walkmeshes in the game, I discovered that they had "walls". By extruding the edges of the walkmesh, and raising them up, you can create walkmesh "barriers" that block line of sight and blaster fire. The polygons of these walls need to be assigned the Non-Walk material. There's not much else to say about this, but it works well. I guess the main lesson is to use the existing KotOR and TSL models as your guide.

 

8. We CAN block camera movement by using the walkmesh injector!

 

This one has plagued us from the beginning, and I'm not sure we can do it with the tools we have. I have determined that the camera is blocked not by the walkmesh, but by the model itself. This makes sense, as things such as characters still block the camera even though they don't have walkmeshes. I'm very open for any discussion into this, as it's one of the last features that existing areas have that we can't duplicate.

 

We can block the camera movement through walls by using Dastardly's Walkmesh Injector!!

 

9. We cannot create area animations through KAurora

 

KAurora currently can't handle animations, but there are several ways around it. Placeables can still be animated through MDLOps, and included in the area. Additionally, it's possible that you could use a faux character model in the same manner. I haven't found the need to experiment much with this yet, but others may want to use it in their areas.

[JCarter426]

This information is all fascinating and helpful, but I've run into a bit of trouble following one part. I've been working on emitters, ideally so I can place a fountain in any module. I've been using the model m05aa_05a for reference - the streams of water coming down from the ceiling in the Taris sewers in those giant pipe areas.

 

You say the easiest way to do this is to take an emitter, export it as its own model, and then include it in the layout file. But I'm stuck in the middle part. I don't see a way to export the emitter on its own as a new model file from KAurora. But if I do anything with the model using MDLOps and 3ds Max, KAurora is no longer able to read the emitter from the model. I must be missing something here.

[Sithspecter]

JCarter, sorry for not responding sooner.

 

To export the individual emitter, it needs to be in it's own ASCII model file exported from 3DSMax, so you'll make an Aurora base, place an emitter at 0.0, 0.0, 0.0 in reference to the base, and then export from 3DSMax. Then, open it in KAurora, change the emitter fields as necessary, and choose "Export to Binary File" under the model tab.

 

Also, the only way to collect emitter data is to load it from the binary .mdl file straight from the game. You can't use MDLOps to convert to an ASCII because MDLOps will corrupt the data.

[Fair Strides 2]

You can't use MDLOps to convert to an ASCII because MDLOps will corrupt the data.

 

And by "MDLOps will corrupt the data.", he means that MDLOps uses different names for a lot of the emitter data, and it tends to leave info blank instead of giving a default value, which of course screws up when trying to import in NWMax.

[JCarter426]

Oh, I see. When you said the easiest way was basing it on one in the game, I thought you meant actually editing the emitter in KAurora... but since it's not isolated that wasn't working out. So you're saying make a new, blank one and then edit that in KAurora, looking at the original to match the values? That doesn't sound too bad. I don't think I'll have a chance to look at it until the weekend, but I hope to have something cool to show by then. Thanks.

[Sithspecter]

Yes, that's the idea! You can tweak as necessary once you've got the basic properties down. Most are pretty self explanatory.