[WIP] L3DEdit: Lemmings 3D Level Editor - Development Topic

[namida]

New topic: https://www.lemmingsforums.net/index.php?topic=4274.0

So, I started work on a new project recently - a long-overdue Lemmings 3D level editor!

It's early days yet. And let's not forget - this is me we're talking about, it's never a sure thing whether or not I'll finish something. But I've made some decent progress already - it can already edit title / stats and some style-related settings, as well as display a very approximate representation of the level's layout.

I'm writing this editor in Lazarus (basically, open-source Delphi). So far I've been using Lazarus 1.8.4 with FPC 3.0.4; but I'm aware of the release of Lazarus 2.0.2 and will likely upgrade this project to it at some point - though as 2.0.2 still uses FPC 3.0.4, I suspect it will compile just fine as-is. There's no compiled version available for download yet because it's simply too far from finished to be worthwhile, but if you're really interested, you're welcome to try and compile it from source:
https://bitbucket.org/namida42/l3dedit/src/master/

At this stage, you're welcome to provide feedback on whether it compiles and/or runs on Mac or Linux, but proper support for them is not a priority yet*. Lazarus very much supports both of those platforms, and there's a very good chance it'll compile and work fine as-is, but if it doesn't, it's on the basis of "fix it yourself; otherwise, feel free to report it and I will eventually look at it, but that's a very long-term eventually".

* Yes, it isn't a priority yet. I do intend for this to be cross-platform.

The only dependency is Graphics32. Either the PilotLogic GR32 package from the Lazarus Online Package Manager, or the copy from the official GitHub repo, will work. GR32_PNG is not required. Note that Graphics32 will only compile under Lazarus when the "PUREPASCAL" conditional define is enabled, at least when compiling from GitHub; I don't know if PilotLogic's version improves on this. This in turn results in slower execution. If this issue in GR32 isn't resolved, I may look at a Delphi port at some point, but only once the Lazarus version is fully working on all platforms.

Huge thanks to Pooty for his work on cracking the Lemmings 3D file formats, without which this project couldn't have even come as far as it has.

If you'd like to help with this project - probably the most useful thing anyone can do at this point, is see if they can figure out any more of the file format - both the LEVEL and BLK file are of interest; I believe I know everything I need to at this point about graphic files. The less time I have to spend figuring out the rest of the format, the more time I can spend making the editor work.



Update: While no release yet (I'll likely create a new topic when there's a release), the first L3DEdit-made level is here. See reply 32 if you'd like to grab a copy and try it out. It's roughly early-to-mid Mayhem difficulty - not a pushover by any means, but you should definitely be able to solve it if you solved the official L3D levels.

[namida]

(reserved)

[namida]

Here's a visual representation of what it can render so far - as you can see, it's got a long way to go, but you can already see the general shape of the levels - I'm sure you can recognize which two levels are in these images!

The first one shows highlighting layers and tiles. There's no actual selection code yet - I just told the rendering code "highlight layer X and tile Y" when generating that image.

There's no full 3D view - that's simply too much work. Instead, the editor will work with an isometric point of view. You can, however, rotate the view - the second and third images show the same level from four different angles. (The 2nd and 3rd images are identical to each other, except one is much smaller; this is because the large one is really big.)

[Flopsy]

This looks really good namida, I'm really interested in seeing how this project progresses.

I would definitely make use of a Lemmings 3D level editor if it existed, I loved the original 3D game and a few levels in SEB Lems are heavily inspired by some levels from 3DLems, as I'm sure you noticed.

It looks a lot more complicated than the NeoLemmix editor and I think using an isometric view is the best way to go about it.
I tend to get a lot of ideas for 3D Lemmings levels when using the NeoLemmix editor but sadly those ideas never get utilised, that's probably how I ended up trying to remake 3D Lemmings levels in 2D in the end.

[namida]

Actually - I think much of the difficulty from this point will be figuring out the remaining unknowns in the level format, which there's still quite a lot of. The actual editing itself, shouldn't be too hard.

For example - rendering has already made progress. Check out these new screenshots. The sky graphic on top of the entrance in the first one is a bug that I've already fixed (notice the absence of the bug in the second shot), but I couldn't be bothered re-taking the screenshot.

[Simon]

Very nice. I think isometric is perfect for editing.

It's merely problematic when you must view rooms from the inside. OpenRCT2 offers cut-away view: User provides a height, then the drawing routines render only blocks below that height. Very powerful.

But others might have more experience with 3D software than I have, and solve the problem much better. Looking forward to what you come up with.

-- Simon

[namida]

It's merely problematic when you must view rooms from the inside. OpenRCT2 offers cut-away view: User provides a height, then the drawing routines render only blocks below that height. Very powerful.

My plan was more or less to do something like that, except on all axes instead of just the Y axis. I had also considered allowing setting a minimum height to render from, but thinking about it now, this seems almost pointless... except maybe if a lower layer is being confused for the one the user is trying to work on..



It seems it should also be trivial to allow importing custom graphics back into L3D - certianly much easier than doing the same for DOS Lemmings was, and we managed that! I'm not going to implement this feature at first, because it'll be nice to simply see what we can create with the official stuff for a while (plus some minor technical questions - more of the "how should I approach this?" kind than the "how can I actually import the data?"), but there's a very good chance it'll come eventually. For the most part, this shouldn't require any 3D graphics skills either, because you're simply drawing flat 2D graphics that represent each face of a cube. Custom sound / music (other than custom CD audio, which is trivial and can be done with any CD burning app) will be over to someone else to figure out, though.

[namida]

I've fixed various issues with the rotation of blocks. New and improved renders of those two levels - and a third, which would've been an absolute mess before.

You probably noticed that most animated tiles aren't displaying correctly - their info isn't quite stored the same way as regular tiles, and I haven't put much into figuring out how they do work yet.

[ccexplore]

I think it'd be good to experiment with tweaking the exact projection details of the view.  The "name of the game" screenshot perfectly illustrates the difficulties of judging distance/height in the current view.   Is the 3 and the D on the same height level with one column of spaces in between, or is the 3 actually one unit higher than the D but touching together at their edges?  In the current perspective the two cases would look exactly the same.  I realize all projection schemes will have such ambiguous cases but maybe tweaking the details can at least make ambiguities less common/apparent in typical cases.  And I suppose being able to view same level in multiple preset camera angles can also perhaps compensate for this issue.

Applying faux-lighting on the 3 visible faces of the cube might also be helpful in enhancing the 3D look.  That is, apply alpha to render the 3 faces at slightly different brightnesses.

[namida]

I think it'd be good to experiment with tweaking the exact projection details of the view.  The "name of the game" screenshot perfectly illustrates the difficulties of judging distance/height in the current view.   Is the 3 and the D on the same height level with one column of spaces in between, or is the 3 actually one unit higher than the D but touching together at their edges?  In the current perspective the two cases would look exactly the same.  I realize all projection schemes will have such ambiguous cases but maybe tweaking the details can at least make ambiguities less common/apparent in typical cases.  And I suppose being able to view same level in multiple preset camera angles can also perhaps compensate for this issue.

I'm considering this - perhaps even to the extent of supporting a couple of different projections.

Applying faux-lighting on the 3 visible faces of the cube might also be helpful in enhancing the 3D look.  That is, apply alpha to render the 3 faces at slightly different brightnesses.

Hm, I'll keep this idea in mind.

[namida]

I'm considering this - perhaps even to the extent of supporting a couple of different projections.

And it's happened.

[kieranmillar]

I just wanted to say that this is really cool. Good luck!

[namida]

I've posted a lot of updates in Discord, but not so much in this topic. Here's a screenshot that does a good job of summing up the recent progress - compare it to earlier screenshots of the same level.

[namida]

The two different pyramid block shapes (compare those on top of the pyramids, to those on top of the poles near the start) really threw me off for a bit. It took me a while to realise they are actually different, I wasn't just repeatedly getting things wrong.

But now, of the 14 not-L3D-crashing block shapes, I've implemented support for 10 of them - the remaining four being 22.5 degree slopes, diagonal corner slopes, and the upside-down equivalents of each.

[namida]

And bam, all 14 known block shapes are supported.

12 of these should be rendered accurately* to how L3D renders them. The last two I have made an intentional decision to forego some accuracy in terms of texture orientation / cropping (while still maintaining accurate shape), simply because the way L3D handles such is really complex and I had already spent far too much time just getting those block types working in general. I suspect that most people will not notice the inaccuracy in question.

* "accurately" here does not quite mean to the extent of "pixel perfect".