Jump to content
miningmanna

LRR remake project

Recommended Posts

miningmanna

Hello RRU community,

 

Me and a friend are working on remaking LRR in Java with the lwjgl and OpenGL.

At first I didnt think, that I would make a topic in this community for our project, since many tries have been made,

and many stopped the development or didnt respond in a long time.

 

But we would like to ask for support, for the following reasons:

1. We would like to make this a bigger project, since it will be quite portable (Java + OpenGL). ie. accessiable

2. Some of the file formats are badly specified, so we (currently me) are working on loading the original lwo and lws files of LRR.

I have already found some information, however some points are a little unclear (http://www.martinreddy.net/gfx/3d/LWOB.txt and http://fileformats.archiveteam.org/wiki/LightWave_Object)

For example the paths for the textures in the lwo files:

"\\Mother\lego\Meshes\Lowpoly\Creatures\slimy_slug\SlugSide.bmp"

which do not match the path inside the original wad file. So I would like to know, if anyone knows, how LRR processes these paths.

3.  As many of you know, making a big project is hard work, and so, it would be nice to be able to split the work

 

If anyone is interrested in helping, parsing the data, writing the shader, or anything you are experienced with, you can submit here.

 

Lastly: I do not have experience with GitHub or any Version handling service, so I am not quite sure, how this project should be made avaliable for everyone...

 

Hoping for some suggestions

 

[Edit]

What I mean by "parsing the data", is parsing the lws, ae, lwo and other types of data used in LRR, into a data container class, to make it accessible for rendering, level construction, etc..

Edited by miningmanna
Explaining what was meant with "parsing the data"

Share this post


Link to post
Share on other sites
jamesster
1 hour ago, miningmanna said:

For example the paths for the textures in the lwo files:

"\\Mother\lego\Meshes\Lowpoly\Creatures\slimy_slug\SlugSide.bmp"

which do not match the path inside the original wad file. So I would like to know, if anyone knows, how LRR processes these paths.

 

As far as I know it always looks for textures in the same folder as the LWO.

 

Meanwhile, there's two ways the LWS files can handle paths to LWOs:

  • Z:\Lego\Data\Buildings\BIGTeleport\TP_SideSlab.lwo
  • \\Mother\lego\Meshes\Lowpoly\Buildings\Big_Teleports\Teleport.lwo

Most of the path is actually irrelevant as far as the game is concerned. The first path will make it look for the LWO in the same folder as the LWS. The second will make it look for the LWO in the World\Shared folder (you could replace it with \\Teleport.lwo and it'd still work fine).

 

This topic may be of interest:

 

 

Also:

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
miningmanna
3 minutes ago, jamesster said:

 

As far as I know it always looks for textures in the same folder as the LWO.

 

Meanwhile, there's two ways the LWS files can handle paths to LWOs:

  • Z:\Lego\Data\Buildings\BIGTeleport\TP_SideSlab.lwo
  • \\Mother\lego\Meshes\Lowpoly\Buildings\Big_Teleports\Teleport.lwo

Most of the path is actually irrelevant as far as the game is concerned. The first path will make it look for the LWO in the same folder as the LWS. The second will make it look for the LWO in the World\Shared folder (you could replace it with \\Teleport.lwo and it'd still work fine).

 

That is true for the most part, however, as example the texture "Newbit_cell_side.bmp", which is used in the Toolstation and the Powerstation are not in their folder, but instead in LegoRR0\World\Shared, while the lwo specifies "\\Mother\lego\Meshes\PC_Meshes\Buildings\Refinery\Newbit_cell_Top.bmp", which is confusing, since it specifies the "Refinery"

 

Same goes for the toolstations T_Pod1.lwo

Share this post


Link to post
Share on other sites
jamesster
21 minutes ago, miningmanna said:

 

That is true for the most part, however, as example the texture "Newbit_cell_side.bmp", which is used in the Toolstation and the Powerstation are not in their folder, but instead in LegoRR0\World\Shared, while the lwo specifies "\\Mother\lego\Meshes\PC_Meshes\Buildings\Refinery\Newbit_cell_Top.bmp", which is confusing, since it specifies the "Refinery"

 

Same goes for the toolstations T_Pod1.lwo

Yes, \\ makes the game look for the file in World\Shared. All the rest of the file path in between (Mother\lego\Meshes\PC_Meshes\Buildings\Refinery\) is 100% ignored by the game. (I wasn't sure if shared textures between LWOs were a thing or not, but it seems they work identically to the paths in the LWS files.)

Share this post


Link to post
Share on other sites
miningmanna

Currently, the struggle is to correctly import the animations in the lws files, and apply them, to make a transformation matrix for every frame in the animation.

 

 

Elsewise, it is looking pretty good. In regards to the stuttering: the animation is supposed to run at 25FPS. Since the framerate of the window is 60, and I was a bit too lazy too interpolate that part, I just went trough each frame of the 25FPS animation for every 10 frames of the window, therefore making it seem laggy

 

  • Like 2

Share this post


Link to post
Share on other sites
miningmanna

Update:

 

Animations are fixed. They are working properly now:

 

Next up is the texture loading and mapping

  • Like 3

Share this post


Link to post
Share on other sites
jamesster

Very nice! Honestly, even just a simple, separate animation viewer would be quite nice, given LightWave is so clunky (and doesn't handle the .uv files for the very low poly raider or or lava monster, either).

  • Thanks 1

Share this post


Link to post
Share on other sites
miningmanna

Looking at the UV files, does anyone know what data represents what?

 

Looking at VLPThighR.uv:

2
4
Thightop
backleg3_top
PILOT_frontleg_tex_upper
backleg3_top_2
Z:\Lego\Data\Mini-Figures\Pilot\A000_Triman.bmp
Z:\Lego\Data\Mini-Figures\Pilot\A000_Triman.bmp
Z:\Lego\Data\Mini-Figures\Pilot\A000_Triman.bmp
Z:\Lego\Data\Mini-Figures\Pilot\A000_Triman.bmp
4
0 3
0.483027 0.753098 0
0.451062 0.753115 0
0.465890 0.750559 0
1 3
0.067408 0.750195 0
0.121429 0.750195 0
0.094055 0.805536 0
2 3
0.432860 0.750373 0
0.497021 0.750373 0
0.470089 0.803438 0
3 3
0.135295 0.751726 0
0.161199 0.806170 0
0.182506 0.750966 0
4
-90.000000 0.000000 0.000000
0.000000 0.000000 0.000000
0.008000 0.000000 -0.016500
0.929200 0.964600 0.760530
4
0.000000 -90.000000 0.000000
0.000000 0.000000 0.000000
0.223733 -0.810000 -0.027765
1.318100 1.636200 1.387576
4
0.000000 0.000000 0.000000
0.000000 0.000000 0.000000
-0.048189 -0.801211 0.257657
1.636200 1.624004 1.630102
4
0.000000 -90.000000 0.000000
0.000000 0.000000 0.000000
-0.197706 -0.810000 -0.058271
1.318100 1.636200 1.402497

There are 4 triangles specified, each for a Surface inside the lwo files surfaces, however, I cant figure out, what the last 4 blocks mean, specifying 4 3d Vectors each


The first one looks like a rotation, but on what sense whould you use a rotation for uv coordinates?

In regards of the other 3 vectors, I have no clue...

 

I`ve seen, that there is a tool for these files. The tool could help finding out the vectors purposes.

 

Any information on the files build-up, or if the UView tool is accessible?

 

Share this post


Link to post
Share on other sites
jamesster

A while back I manually transplanted the UV coordinates to OBJ exports of the LWOs, and didn't know what those last 4 blocks were either... They didn't seem required to get proper UV mapping, so they must be for something else:

 

CzPqaO8.png

 

Maybe try editing them, and seeing what changes in-game?

  • Thanks 1

Share this post


Link to post
Share on other sites
miningmanna

Update:

 

I have applied the UV files, and yes, it looks quite good.

 

If anyone was wondering: the resolution is low, since im recording a window with 600*400 pixels, but I could increase the resolution at any time.

 

 

I guess now its time to make the setup more rigid, it is currently quite flimsy, since I just wanted to see if it even works, but now I can improve that.

I could work on animationViewer as side project. I´d imagine it would be quite helpfull for modding

 

PS:

I could also implement the conversion from planar texture mapping to UV, since that is what I will be using anyways

  • Like 2

Share this post


Link to post
Share on other sites
Cyrem

This is looking really good. Great work so far.

 

A seperate tool to view animations/models would be awesome, it's really one tool we're definitely lacking.

Share this post


Link to post
Share on other sites
miningmanna

I`ve implemented planar mapping now:

 

I only demonstrate with one texture here, but I only need to redo the draw method a bit, and I will be able to use all textures.

 

I have also found a bug, in regards to scale values. It was not noticeable in most cases, however the slugs animations looked a bit funny at times, and in a video (actually from some user on this forum), shows that in the animation NEW_Captain_Point_CALL_T_ARMS.lws he lifts his left arm, while in my program, he has lifted his right arm.

 

My draw function is missing to use the correct texture for a given surface. My shader is also too simple to simply render it correctly, so I´ll have to write a new shader aswell

  • Like 2

Share this post


Link to post
Share on other sites
miningmanna

A simple way to load the models is now implemented. Image alpha is also working, but suboptimal. If anyone knows about color keying in GLSL, feel free to suggest a code snippet, or explain. I´ll try to look at color keying myself.

 

Results:

 

  • Like 3

Share this post


Link to post
Share on other sites
miningmanna

For now, I cant quite figure it out with the color keying... When loading buildings there are files, which do not mark the index of the alpha color in their name, however the background is black. These files ("spangleY.bmp" as example) seem to be treated specially. Maybe I just need to check the flags for the given Surface in the LWO file? But it seems it is additive color. If it would have been blended in respects to its alpha values via keying, the black color would stick out.

 

For now, I will work on loading the data out of the WAD files, since it is faster to copy, easier to share than hundreds of files and subfolders.

As far as I know, WAD files are used in more places, such as Doom (ZDoom) specifically, but their wiki says, that the header is 12 bytes long:

 

0x00-0x03 : "PWAD" or "IWAD"

0x04-0x07 : integer representing the size of the lump

0x08-0x0F : ASCII String defining the name of the lump

 

First of all, the the first four bytes in the LRR wads are: "WWAD"

then comes a null character, and directly after that the file names...

 

I tried searching for the format, but could only find the Tools you guys already made...

 

Cyrem, you know the structure, since you wrote the tool, would you be kind to explain the format?

Share this post


Link to post
Share on other sites
jamesster
1 hour ago, miningmanna said:

For now, I cant quite figure it out with the color keying... When loading buildings there are files, which do not mark the index of the alpha color in their name, however the background is black. These files ("spangleY.bmp" as example) seem to be treated specially. Maybe I just need to check the flags for the given Surface in the LWO file? But it seems it is additive color. If it would have been blended in respects to its alpha values via keying, the black color would stick out.

Yeah, in those cases I think it's handled within the LWO. There's no alpha channel on BMPs as far as I'm aware, transparency is instead how close to black or white the RGB values are:

 

On 12/30/2015 at 12:18 PM, Cirevam said:

... transparent particle effects which works by treating pure black (000,000,000) as fully transparent, pure white (255,255,255) as fully opaque, and everything else inbetween partially transparent. Then, in the Surface Editor in Lightwave Modeler, you have to go to the Advanced tab and set Additive Transparency to 100%.

 

 

 

 

1 hour ago, miningmanna said:

As far as I know, WAD files are used in more places, such as Doom (ZDoom) specifically, but their wiki says, that the header is 12 bytes long:

There's no relation between the formats, they just both happen to have "WAD" as the extension. It's very common for people to use the same extensions for completely unrelated formats.

  • Thanks 1

Share this post


Link to post
Share on other sites
miningmanna

Thanks jamesster :D

 

I´ve looked at the FLAG section of the surfaces. The surface: "slug_Slime", which is the surface the slugs trail uses, has the flag bit "Additive", meaning additive colors enabled. I can just change the OpenGL Blend function, when it is additive or not, and it should be correct with its transparity.

 

997721913_Consoleadditiveflag.PNG.5c477a07e4c7f3f09f2dd47e9e9f5b0c.PNG

 

I'll post the results, for the Slug and some Buildings later.

Share this post


Link to post
Share on other sites
Cyrem
17 hours ago, miningmanna said:

For now, I will work on loading the data out of the WAD files

 

If you could I would recommend still allowing loading the files themselves from folder in addition to archives. While it's easier for distribution, it's a pain for modding to extract and re-pack archives. Most of us do not use WAD files in our installations because of this, apart from overhauls.

 

WAD files are a simple format, in summary:

  • "WWAD"
  • File Count
  • File Paths
  • Original Source File Paths [redundant]
  • Information about each file
    • compression status [redundant because there is no compression]
    • size compressed [redundant - as above]
    • file size
    • data offset
  • file data
  • Thanks 1

Share this post


Link to post
Share on other sites
miningmanna

Sorry, it took a little longer.

 

I had some issues with OpenGL:

To use the translucent objects (sparks, lighting effect, etc.), I had to make sure they dont write into the depth buffer, since that would make objects behind it invisible. Howerver, since I drew the translucent surfaces last, the function to deny writing to the depth buffer (glDepthMask) was called last. For some reason, OpenGL wont let you clear the depth buffer, if you have the depth masking disabled. So everything just disappeared after some moving around.

 

Besides the issues with OpenGL, I had to prepare a bit for the impending moving of me to the city, where I will study next month. I will not stop this project, since I started it knowing, that I will be studying. However, for the next 1-2 weeks, progress might be a bit slower.

 

Results:

Also: Some things still seem odd. I will look into those. Such as the "Z"s with the monsters seem to be bottles. I am probably not planar mapping them properly I guess. Linear image resizing will be done in the shader, since elsewise, the alpha color for the textures: "A###_texname.bmp" will not be applied properly.

 

In regards to the concern with the WAD files:

I would probably make a tool, so that you can export your modding as WAD, and then can share them easily in the forums. WADs are just faster to copy than a huge tree of files.

You can suggest some tools, that would make the use of the WADs for sharing way easier, I have some ideas, but more wouldnt hurt

  • Like 2

Share this post


Link to post
Share on other sites
miningmanna

I have found the reason for the weird "Z"s:

 

Apparently Lightwave has only onesided faces, however you can set them to to-sided. In this case however, since the "Z"s would be mirrored, each Z is made of 2 surfaces with the character on it, so that turning it 180 degrees doesnt mirror it.

 

 

There are more instances of this: for example the spade in the toolis store made of a front and a backside, which had Z fighting, since there was no face culling. The jackhammer at the tool store aswell, however it would not be needed. Also the jackhammer textures name has a alpha index, but for some reason it starts with a lower "a" and not a capital "A". There is one more issue with it aswell. The index isnt right. X or Y index doesnt matter, it doesnt fit.

Has someone maybe some info on that?

  • Like 2

Share this post


Link to post
Share on other sites
aidenpons

Fantastic work! There's got to be an emoji in the 1000+ RRU now supports that describes my reaction (and also that lags my laptop when loading)... aha! How about this one? 🧙‍♂️You're a wizard at this 👾old pixellated game!

  • Like 1

Share this post


Link to post
Share on other sites
miningmanna

Ok, I have implemented sequenced textures, so we can see the captain in his full glory now and can enjoy the nice steam effects.

 

WAD files can now be read just like a normal Java InputStream.

However, the lamps on the Barracks seem to have something weird about their alphaindex, which led me to be confused. I´ve looked at the "Invisible colors" thread, however, it didnt help much. The indices are all in the x axis of the image, right? if the index is higher than the width of the image, it skips to the next y line, is what I am asuming.

Some more details would be nice. The names of the textures are:

- "A255_redlightside.bmp"

- "A168_yellightside.bmp"

 

For some reason, even though the seem to be just a different color, they got different alpha indices.

 

FYI: the Z-fighting of the braced supports, and the wrong colors behind the lamps are exactly the way they are in the game, so no worries there.

  • Like 2

Share this post


Link to post
Share on other sites
jamesster
4 hours ago, miningmanna said:

However, the lamps on the Barracks seem to have something weird about their alphaindex, which led me to be confused. I´ve looked at the "Invisible colors" thread, however, it didnt help much. The indices are all in the x axis of the image, right? if the index is higher than the width of the image, it skips to the next y line, is what I am asuming.

Never worked with them myself, could be wrong, but I always assumed it referred to the color table/palette, not a pixel:

https://en.wikipedia.org/wiki/BMP_file_format#Color_table

(Don't know if the info there is relevant to LRR's BMPs, specifically - I forgot which kind of BMP they are and don't know much about what variations in the format exist - but it might be a push in the right direction at least.)

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Cirevam
11 hours ago, miningmanna said:

The indices are all in the x axis of the image, right? if the index is higher than the width of the image, it skips to the next y line, is what I am asuming.

 

I'm sorry for the confusion. When I mentioned color indexes, I meant the number for a color in the image's color map. LRR uses 8-bit indexed bitmaps (but you probably already know this) which means each pixel points to a color instead of defining the color on its own. An image starting with A168 is saying "whatever color is labeled 168 in the color index will be treated as transparent." If you have GIMP, you can open one of these images and go to Tools -> Map -> Rearrange Colormap. This will let you confirm that the transparent color matches the index you defined. There's a ton of black in the example below, so using something extraordinary, like magenta in this mostly yellow image, will help you confirm this further. I'm not sure if the game will treat black as any of those colors past 168. I doubt it since it's looking at the index instead of the actual color.

 

large.Colormap.png.009045deb41cb43b5cb1a

  • Thanks 1

Share this post


Link to post
Share on other sites
miningmanna

I was able to get the color table, so now its only a matter of implementing it in the loader.

Since I just used the 2d position on the texture in the shader, I will have to change that too, but noting severe.

RightColorPal.PNG.812d6f6977ddb774939a3de3e4568791.PNG

 

Thanks for the responses Cirevam and jamesster ^^

If any of you are interrested in getting the project files and libs, I could give you them. You could try to load different models, and just try it out.

My guess is, you guys have expirience with programming, since you have written map editors, patches and more for the game. Though it was probably not Java.

I could leave some comments, so you could find the important variables fast, and also make a video for the eclipse project setup, if you are not familiar with it.

  • Like 1

Share this post


Link to post
Share on other sites
miningmanna

Implemented and working:

I still need to fix the issue with the wrong movement of the "telepthing" as its lwo file is called. The blue outline of the buildings base. Probably the same issue, that is causing the top of the upgrade station to levitate currently.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.