Leaderboard

For those who don't know, in the days of Rock Raiders' development, LightWave didn't have built-in functionality for UV mapping. This wasn't exactly great. So another company, CineGraphics, made UView, a program that could interface with LightWave and do UV mapping! It cost like 700 bucks. https://groups.google.com/d/msg/comp.graphics.apps.lightwave/Z4eU-fBcF5g/7QCmsagFK2YJ http://web.archive.org/web/19981205124926/https://www.cinegraphics.net/Products/uview.html It seems CineGraphics is still around, but their own link to UView leads to the web archives: https://www.cinegraphics.net/ https://web.archive.org/web/20010803011902/http://cinegraphics.net/product.php?location=UView Karl thought that UView was probably used for LRR, but wasn't sure: Later, LightWave overhauled their format and also added built-in support for UV mapping, rendering UView obsolete. But, there's a plugin that loads ye olde UView (.uv) files into newer versions of LightWave, turning their data into modernized UV data stored right in the LWO file: http://www.dstorm.co.jp/dsproducts/FreePlugins/Image_IO/UView_Import.html And lo and behold, it works with LRR's .uv files! Guess that confirms DDI did use UView. For like, the two creatures in the game (triman and lava monster) that use .uv files, anyway. Just be sure to read the readme; in short, you have to manually select the texture image and assign it to the surfaces due to a limitation in the plugins system. But it works! So is this useful for modding? Not really. In order to make .uv files that LRR can read, we'd either need UView itself (seems to be lost to time?), or a custom tool. I'm currently working on the latter. But hey, we know what originally produced them, at least. And if for some reason you want to directly upgrade LRR models to newer versions of LightWave, you can I guess, lol.

First post. I hope this is the right sub-forum. Anyway, several years ago I started making a strategy RPG in RPG Maker using graphics created in LDraw. Here are some videos. https://youtu.be/yyabknNfsR8 https://youtu.be/AFnHTKgOA9A https://youtu.be/MTkwaZ4Y7f0?list=PLov7Lq9jgP0HoegSIMg9KPChvD54XzYSy I will probably not be making further updates. The combat scripts were never completed, AFAIK, and RPG Maker simply is not designed to handle complex layered sprites of this type. Just thought somebody might be interested. [edit] Not sure what the proper way to embed YouTube videos is.

Nice! What kind of remaster are you trying to do like recreate the maps or just get the game files of maps?

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. (A forum upgrade broke that link...) (Sadly, a forum upgrade broke that link too...) 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