Rock Raiders models - .uv files, .x files, texture filtering, and the shared folder

[lol username]

Unsure how much any of this has been discussed in years past. Had some chats with Cire and others about all this a few months back and there was a lot of shrugging and new discoveries, so maybe it's time for a topic.

 

---

 

.uv files

These only exist for the lowest poly minifigure (triman) and lava monster, as far as I know. Most models in the game use other methods of texture mapping (planar textures), but these files have specifically defined UV coordinates. The game will check for .uv files for every model, and if they're present, try to use their coordinates. The format is super simple, and text based, try opening one in a text editor and you can see how they work.

 

These files may have been created by a custom tool DDI made (which also did a zillion other things), or by something called UView, according to Karl. It sounds like the process may have changed at some point, and his memory was fuzzy on which tool was used in the end.

 

On 12/18/2010 at 1:37 PM, rrcoder said:

The map editor was a separate tool that was buggy and crashed constantly. I found myself saving every 30 seconds just to prevent losing all my work. It was actually an evolved version of the map tool used on Conquest Earth. This tool was also used for applying UV texture mapping to the animation models, since the version of Lightwave we used (v5.0) didn't support UV maps. We later switched to LW5.6 which (if I recall correctly) added support for UV maps.

 

I haven't seen or used this tool since shortly after the release of RR, so I wouldn't know where to begin looking for it. It probably got backed up to a tape drive, and archived away somewhere never to be see or heard from again. From what I can tell Cyrem's map editting tool is *far far* more stable and usable than what I had to work with!!

(A forum upgrade broke that link...)

 

On 12/18/2010 at 1:37 PM, rrcoder said:

(Dull trivia: The original map-editor/UV-mapper tool also packaged the Wad files).

 

 

On 12/18/2010 at 5:50 PM, rrcoder said:

I also vaguely remember us using a tool called UView for applying texture maps. Again, I can't remember whether this was still used towards the end of development, or whether we dropped it during development sometime. If UV mapping is something any of you have had difficulties with, then it may be worth trying to track down this UView application. Its specific purpose was to apply UV maps to Lightwave models.

 

 

On 12/18/2010 at 5:57 PM, rrcoder said:

In fact, I've found a Lightwave plugin that reads the .uv files that were created with UView. Not sure if this will be of any use.

 

(Sadly, a forum upgrade broke that link too...)

 

On 1/18/2011 at 5:24 PM, rrcoder said:

1. I don't know, unfortunately. I simply used a tool created by another programmer to encode the videos, so I didn't know anything about the tool's internals. I should also note that it was the same tool used to create the maps, and to apply texture maps before Lightwave natively supported UV mapping. It was a single tool that pretty much did all of our conversions.

 

2. See above. One tool to rule them all.

 

 

For more, see the full topic: http://www.rockraidersunited.com/topic/2132-wow-people-i-am-both-stunned-and-impressed/

Bartvbl thought he'd found a possible lead for UView and posted about it there, but I didn't want to spam more quotes than necessary.

 

Back in December I wanted to get the triman model into Unity, so I manually transplanted the coordinates from the .uv files into exported .obj versions of the models (with a little bit of trial and error to figure out the order the coordinates should go in, etc). Here it is next to the highest poly minifigure (which lacks textures, since none of the export methods I tried generated UVs from the planar texture info...).

 

 

 

This is also why the game will crash if you replace the VLP minifigure files with HP versions without removing the .uv files; it'll be trying to apply the UV coordinates to a model with way more verts than those defined in the .uv files.

 

Is there a need to figure out how to make new UV files? Probably not. We can already do planar textures, 99% of the vanilla game uses them, and that's usually good enough. You probably only need to look into them if you want textured exports of the triman or lava monster.

 

---

 

.x files

The game has copies of some models in a standard .x format. Is the game capable of loading them? Did an artist just save in the wrong format accidentally and never remove them? Were they for some other purpose? Who knows. Nobody's looked into them that much, apparently. They've got proper UVs generated from the planar textures, though, which is nice. (Which appear flipped in the program I'm using in the screenshots below but such inconsistencies are aggravatingly common in 3D things...)

 

Some chat logs from December:

 

[8:49 PM] Terrev: whaaa

[8:49 PM] Terrev: LP_SmallWheel.x

[8:49 PM] Terrev: are these....

[8:50 PM] Terrev: GD_Standard.x

[8:50 PM] Terrev: just standard directx models?

[8:53 PM] Cyrem: I think the colours are good

[8:55 PM] Cyrem: @Terrev textures seem messed up

[8:55 PM] Terrev: yeah, flipped

[8:55 PM] Cirevam: No, that's because you're in Australia

[8:55 PM] Cirevam: It's right-side up for me

[8:55 PM] Terrev: I'm just curious why there's random directx models sprinkled around the vanilla game

[8:55 PM] Cyrem: haha

[8:56 PM] Cyrem: that is odd and I never noticed

[8:56 PM] Terrev: presumably not used for anything?

[8:56 PM] Cirevam: It would be great if LRR could read them

[8:56 PM] Cyrem: wonder if it can

[8:56 PM] Terrev: welp, one of you test that, I should go get food soonish

[8:56 PM] Cyrem: I'm busy getting coffee

[8:57 PM] Cirevam: I'm busy making mods that will never get used

[8:57 PM] Terrev: hmmmm

[8:57 PM] Cyrem: @Jobbo its in your hands

[8:57 PM] Cirevam: :thinking:

[8:58 PM] Jobbo: I'm busying setting up The Room movie night

 

(And then nobody looked into them further. Oops.)

 

---

 

Texture filtering (pixel blending)

Back in January I noticed texture filtering in LRR was inconsistent, and Cire tracked down what controls it.

 

 

Look at this minifig, for example - the front of the torso (but not the sides or back) is getting point filtering (think Minecraft), the face is getting bilinear filtering (smoothed out).

 

Another example is the Power Station. The sides have point filtering to get a nice crisp look between "bricks", the front is getting bilinear filtering. And the stripes are getting point filtering. Maybe they had their reasons for these choices, but it looks a bit odd to me.

 

 

I attempted changing it, which worked!... Kinda. All the surfaces in the lwo that I didn't touch broke, somehow. Oh well. Cire explained what had happened (something about garbage data) but whatevs, I didn't care to poke at it much more.

 

 

Here's the surface settings that control it, with the sides and front of the vanilla Power Station for an example. I'm unsure if the "texture antialiasing" option is used by LRR, but "pixel blending" is.

 

 

 

Also note that Lightwave/the modeler seems to render models in its viewport ignoring the pixel blending settings for surfaces. Instead it changes how it renders textures based on distance, for whatever reason. It doesn't affect the models of course; just don't be surprised when they don't look like you'd expect within the modeler.

 

 

---

 

Controlling usage of the shared folder

More from December and January (all of this is, actually). This post is already lengthy so I'll cut to the chase, important parts in yellow.

 

[9:08 PM] Terrev: is there anything in the LWS files that reference the shared folders

[9:09 PM] Cirevam: The filepath of the model, but exporting the file again makes it lose that somehow

 

[5:18 PM] Terrev: LWS files are plain text, and looking at Big_teleport.lws I'm seeing two types of file paths

[5:18 PM] Terrev: Z:\Lego\Data\Buildings\BIGTeleport\TP_SideSlab.lwo and \\Mother\lego\Meshes\Lowpoly\Buildings\Big_Teleports\Teleport.lwo

[5:19 PM] Terrev: maybe if the path is relative it looks in shared?

 

[5:20 PM] Terrev: I'd been toying with the idea of making a tool to automatically patch LWO and LWS files with paths to your own working LRR directory

[5:20 PM] Terrev: to make loading with lightwave less of a hassle

[5:21 PM] Terrev: LWS files would be easy enough but I'm scared to touch the binary LWOs lol

 

[7:48 PM] Cirevam: I think I know how to make it point to Shared but it involves manually editing links in the LWS file to point to the imaginary locations that the devs used

[7:48 PM] Terrev: hmm if the file paths in LWS files work like I think they might, you could make a little tool to automatically point them towards any world\shared files that exist there

[7:48 PM] Cirevam: They look like LoadObject E:\LEGO Media\Lego Rock Raiders\Data\Buildings\ToolStation\SchneiderCS.lwo

[7:49 PM] Cirevam: BIGTeleport's animations have links like LoadObject \Mother\lego\Meshes\Lowpoly\Buildings\Big_Teleports\Teleport.lwo

[7:49 PM] Cirevam: \\Mother is obviously not a valid location

[7:49 PM] Terrev: I think I literally posted that exact path in this channel a little ways up haha

[7:50 PM] Terrev: I wonder if it's just the "does it start with a path to a drive or just \\" part that matters

[7:51 PM] Terrev: and not the actual path beyond that

[7:51 PM] Cirevam: Testing

[7:51 PM] Cirevam: LoadObject \\Teleport.lwo This will surely work

 

[7:57 PM] Cirevam: Hooray, the game doesn't care what the path is

[7:58 PM] Cirevam: I will try to replace it with a different model just to make sure

[8:02 PM] Cirevam: Looks like we're good to go! \\objectname.lwo will force the game to look in World\Shared

 

[8:04 PM] PWNZOR: Will it still default to the local folder?

[8:05 PM] Cirevam: No, I changed Teleport.lwo to Bigwheel.lwo and the game loaded it

[8:05 PM] Terrev: [galaxy brain] put everything inside world\shared

[8:05 PM] PWNZOR: plz no

[8:05 PM] Cirevam: PLZ YES

[8:05 PM] Cirevam: This knowledge will save me dozens of MB

 

[8:07 PM] Cirevam: But really, the animated teleport beam effect I'm using is 8.06 MB and I duplicated it for each ship that's using it

[8:07 PM] PWNZOR: e.e that's huge man

[8:08 PM] Cirevam: 64 512x256 pixel 8-bit bitmaps

[berylliumquestion]

I was poking around in the shared folders, but what I don't understand is why there's duplicates like with LegoRR0/Mini-Figures and LegoRR0/World/Shared. Does the game really use both of them or does it only use the shared folder and the others are vestigial?

[Cirevam]

The duplicates are vestigial in a sense. Files located in two places are probably both being used, but by two different things. You can only tell a model or animation to use one location or the other, since the definition is a single file path. The game does not default to Shared; it actually defaults to the root folder that contains the model or animation calling the target file. My own creations can point to file paths that do not exist, and the game still looks in the root folder. That's why it took us so long to figure out how to make things look in the Shared folder. I thought the devs' paths like \\Mother and \\StarTeam were treated like any other.

 

The game has duplicates all over the place, so it's not really surprising to find some. The files you found were probably put in two locations inadvertently if the Shared folder wasn't used by all devs or if it didn't exist from Day 1. Maybe shared functionality was added later. It's messy, but it's not as bad as Lego Island 2.

[lol username]

Update:

 

 

I'm also working on a new tool to create LWO + UV files without relying on LightWave or UView, stay tuned.